GNOME Bugzilla – Bug 324942
Impossible to not have an empty last line
Last modified: 2011-09-13 17:32:45 UTC
Please describe the problem: When opening a file in gEdit there is always an empty line at the bottom of the document. One can remove this line but when saving the document gEdit will sneakily insert a "\n" at the end of the document anyway. gEdit should either not insert this extra "\n" (my preference) or its UI should not make you think that you can delete this extra line. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
why? This is done on purpose, some command line tools get confused by text files missing a final \n. vim behaves in the same way.
Ah. Right. I should know that, but vim behaviour never seemed odd too me. There's a slight difference between vim and gEdit though. Vim never shows an empty last line. It just cuts it and displays a ~. Maybe gEdit could adopt this behaviour too? I guess it just feels weird to me that when I open a document there's always an extra empty line. Of course, I could probably get used to it...
Well, as Jonas suggested we could implement the vim behavior. pbor: what do you think?
Fine by me, but I have not though much if this would cause some implementation burden with how we feed the buffer to GtkTextView
This "feature" causes much trouble for me, as an empty last line is added on every file opened by gEdit. In PHP, an empty last line signalises that it should output that line, and that makes it impossible to alter HTTP headers, as they already have been sendt when the whitespace was outputted. This means that if the file edited in gedit is a part of a larger script (it often is), it will wreck havoc across the system and destroy login features and everything that deals with HTTP headers, in addition to spawning a lot of warnings and errors by the PHP parser. As a PHP developer who uses gedit for quick code edits (Zend Studio takes too long to load for a small fix), this is really important for me, so I hope this will be fixed in 2.14 (the one that Ubuntu 6.40 will use). :)
AFAIK, this is not true, since PHP does not take care of the \n following the closing tag, and so PHP does not send headers because of that last empty line. I use gedit with PHP for ages and I've never encountered the issue you're talking about right now.
ANY whitespace after ?>, even if it is on the same line as ?> is outputted by PHP. So if you just have a \n, it will still output it and cause trouble. I don't know how it is for you, but every time I edit a PHP document in gedit, it inserts a blank line (that is not visible in gedit until i re-open the document). Every time that happens, PHP complains and says that "output started on ...", and points to the file I edited on the line that gedit added. It causes serious trouble to me, as I then have to edit the last line away in another editor, like ZDE.
I'm currently running gedit 2.14.0 and while I do see that empty line in gedit, it is not interfering with PHP5. My test case consited of two php files, index.php: <?php include("test.php"); header("Location: http://google.com"); ?> test.php: <?php $i=0; ?> If the blank line was being seen as a real empty line by PHP, I should get an error that headers had already been sent out in test.php. Instead when I go to this page I'm redirected to google. It would probably be ideal if the line didn't show up at all in gedit, but it does not appear to be causing problems in 2.14.0.
Created attachment 77163 [details] [review] patch + * gedit/gedit-document-loader.c: don't add the trailing \n to the + buffer (to avoid having an empty last line). This is the way vim does. + Fixes bug #324942. + + * gedit/gedit-document-saver.c: always add a trailing \n (to be + consistent with the way the loader works).
Patch looks good to me. As said on irc just add a comment to the saver code.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.
*** Bug 658891 has been marked as a duplicate of this bug. ***