I have yet to see an actual consequence on files. In particular, the "bad consequence" in PHP files is a myth, PHP strips the trailing newline if you don't have any other character after the trailing \n.

Btw, this behaviour is consistent with vim.

This behavior is dissimilar to editors that are like gedit in simplicity. I have no experience with php and issues claimed by the ubuntu bug. I discovered this issue while writing html templates for django web2py and ruby on rails. I would occassionally receive unusually excessive newlines in preformatted areas undesirably so i discontinued using gedit and installed kde, since kate didn't do annoying things. I still prefer gnome apps but as far as being user friendly gedit failed by silently adding lines. Ill remind you vim isn't known for simplicity, gedit is.

The only thing that happens is that a file always ends with a newline (which other utilities, like 'cat' rely on). This has nothing to do with being a 'simple' editor or not. There are no added newlines in any other pieces of the file and gedit will also not add additional newlines each time you edit the file (it only makes sure it ends with a newline).

The assumption that ALL files will be fine with a newline is a disturbing stance. Jesse, i understand that it only adds a newline at the end of the file, but you make the assumption that an end of file newline is negligible. If i write html in gedit and sprinkle it with django templating language, i could include another gedit file which is its own file and that newline has no effect. When i include it, however, the trailing newline (which i can't even see in gedit) is also added into a template, meaning it is posible that this newline could be anywhere in the middle of my html when it is assembled by the server and your newline will be nonnegligible. Before you call out django for this behavior, you should know that ruby on rails and web2py also include that newline. Please just admit that this is a misfeature and acknowledge that the proposed changes allow the flexibility to make this less annoying: 1. Make it obvious that the newline is added by actually showing it so i know why things are screwed up. 2. Maybe give me a box to turn off this behavior since i know when whitespace is negligible.

Gedit Killed WordPress admin by adding space after PHP closing tag in functions.php.  Tested it several times and I keep getting the "WordPress White Screen Of Death".  I then edited functions.php with Geany and I can now fully access wp-admin.

*** Bug 652943 has been marked as a duplicate of this bug. ***

Are the already-reported consequences of this feature enough to demonstrate that there are in fact problems with not allowing it to be turned off?  Why is this still marked "UNCONFIRMED"?

What would need to happen for there to be any progress on this?  I am more than willing to generate as many possible "fallout cases" as I can, but David Felix's and Tracy's already-described issues with many major web frameworks/languages seem pretty convincing to me.  If not, what would count as an "important enough" side-effect?  A security issue, perhaps?

Are there any known workarounds (short of modifying the source and recompiling)?  Perhaps a plugin which can provide me an option?  I've tried <https://github.com/dinkel/gedit-whitespace-remover/>, but that doesn't seem to be able to kill the extra "secret" newline.

I realize that vim and several other editors have similar behavior by default, but as far as I know all of them have an option (or command-line flag) to disable it.  The fact that the extra newline doesn't even show up as a line number makes this feature incredibly surprising to the point of seeming purposefully obtuse.  If there's some unknown rationale for this that I'm missing, please educate me.

I am an open source developer and I find this bug particularly pernicious. At least give us some way of configuring it away, if you won't give us a checkbox in Preferences, at least give us an option in GConf. Having unnecessary EOF whitespace changes show up in my git commits is annoying. Some of us also use obtuse data processing tools where EOF whitespace is significant.

Sorry, but just because Steve Frécinaux doesn't think there are any consequences, doesn't mean that there aren't any, in fact, out here in the real world, where we humble users actually use your program day to day, for real work.

As I said in my first comment, I have yet to see a case where this would cause an issue. A real world example would be nice.

Anyway, proposing a patch implementing what you said and displaying a marker when there is no EOL at the end of the file (similar to what vi does) would be a first step.

BTW UNCONFIRMED just means the bug hasn't been fixed or rejected. There is no semantic difference between NEW and UNCONFIRMED, at least for the gedit project.

It's clear that this is a real problem for some people, as we keep getting hits on this report. I don't want to start some kind of meaningless flame war, but if tools like RoR or django do not work correctly with files that end on newlines, it's a bug. Btw, in RoR, just use <%- -%> to strip that trailing newline if you have to (http://ap.rubyonrails.org/classes/ActionView/Base.html). For django, see https://code.djangoproject.com/ticket/2594. Also, did you ever try to use the bash 'while read' on a file without a trailing newline, you can't actually read the last line like that (without the newline).

That said, we can all agree that even though we are of the opinion that in a perfect world we are right, and all text files should have a trailing newline (and they should), we can also agree that the world is not perfect.

For everyone, please focus on the issue. Things like this:

"out here in the real world, where we humble users actually use your program day to day, for real work."

is not going to make us work on this faster. We use gedit everyday for real work as well.

For the solution to this problem:

1) A plugin to strip the newline after each save. This cannot really be integrated correctly because gedit will notice the file was modified externally which is annoying, and it's not so trivial to get it right with saving on remote files, moving after backup etc.

2) Integrate in gedit, partly. Save a document in the same manner as it was loaded (i.e. do not add a trailing newline when it was not there originally).

3) Integrate in gedit fully:
2.1) Add a flag on the document to indicate whether trailing newlines should be added or not.
2.2) Add a check in the save/save-as dialog to indicate saving without trailing newlines.
2.3) Add a visual indication whether or not the doc will be saved with trailing newline.

Can we just go for the gsettings option? If the user modifies that option he/she should know what is doing :)

I still think that supporting solution 2) would be good, since that way we preserve the original file better.

The Principle of Least Astonishment dictates that silent changes to files that in some corner cases can cause unexpected or even erroneous results elsewhere, should not happen.

However, since in the majority of cases the user probably wants gedit to always silently correct the EOF newline (as happens now), this behaviour should be controlled by a setting which is enabled by default. This means that out of the box, nothing has changed, but it allows us weirdos with funny scientific programs or crusty compilers to turn it off. Since that would be a corner case, I believe it doesn't necessarily have to be a checkbox in the Preferences dialog (since I know that can be a tricky decision), it could just be a key in GConf with a very simple three-liner patch to check the value of the key in the appropriate piece of code.

With the behaviour turned off, gedit would revert to option 2 above (the file is saved un-fixed). The "fixing" is then a conscious act. Adding a clickable error marker at the EOF sounds cool-but-fiddly, whereas an in-tab pop-up warning similar to the one that appears when the contents have changed on disk, might be easier and more UI self-consistent.

Created attachment 206441 [details] [review]
Add gsettings option to enable/disable newline fixing

This patch adds a boolean gsettings option to enable/disable the automatic newline ending fixing while loading/saving a document. By default the setting is enable, i.e. nothing changes. When disabled, gedit will stop removing trailing new lines when loading a doc, and will stop writing a trailing newline (if needed) when saving the doc.

Review of attachment 206441 [details] [review]:

Looks good. Just a minor comment. Also would be cool to have an commander option for this maybe?

::: gedit/gedit-document-loader.c
@@ +248,3 @@
 	}
 
+	if (priv->editor_settings != NULL)

use g_clear_object

Review of attachment 206441 [details] [review]:

Would be nice I guess to have a commander option for this. Can implement that once this is pushed

::: gedit/gedit-document-loader.c
@@ +248,3 @@
 	}
 
+	if (priv->editor_settings != NULL)

I didn't do that because other code there also still does the unref/NULL stuff. I thought it might be better to be consistent and I didn't want to start fixing all the other code.

I had no idea there'd be that many places to touch per setting, but looks good!

<parade type="street">
  <confetti/>
  <applause/> 
</parade>

:-)

This was fixed some time ago.

*** Bug 698715 has been marked as a duplicate of this bug. ***

I just stumbled across this bug while writing C++ source files.

I'm always in the habit of making sure that my file has a newline at the end.

Unfortunately, gedit's auto-newlining hid the fact that there already was a newline at the end, and that my manually doing it put two of them at the end.

This in turn caused git to red-flag the extra newline during commit.

I would like to suggest this feature be defaulted to off and that gedit by default loads a file as is.  I personally think it was a bad feature to turn on by default because it silently edits files behind your back, and I think that violates good programming principles.

The status of this bug is not RESOLVED FIXED as given but WONTFIX, you have to change this, as Gedit still silently adds newline at end of file.

Nevertheless, I ask you _not_ to add a newline by default (and to allow it via gsettings if you want). So please make it the other way as you “fixed” it now. I agree that an option in GEdit would be to much because GEdit is to simple for such minor details.

It took me some time to find the error in my C++ program – there was none, it was GEdit. I need to have the full control of all characters in a text editor, that’s the reason for using a simple editor. I think the main problem is, that the silently added new line is not even shown. Of course, I could use another editor, but this cannot seriously be the wish of the developers, and moreover GEdit is (unfortunately?) the default editor of my OS.

You can read all the comments here and on similar bug reports, everyone says that this behaviour is annoying, it’s really simple:
Silently adding a newline is unpredictable, irritating and FALSE.

Please change it instead of setting this bug to WONTFIX.

Hi

Agree.
Gedit (Pluma!) is so a nice editor which for first time when I saw this bug, I couldn't imagine that it is a feature!!

Adding or Hiding a character of a file without notice, each causes general troubles in checksum operations, comparison operations, and programming works as described by other users.

I always have to finally open the file with Kate to see whats about the end, and correct it if necessary.

Irony is that since developers considered EOL@EOF as very important, they made a feature to set a wrong EOL at most cases and made it obligatory and hidden!!!

The story goes worse when the program does this only with unix texts, not for dos or mac texts and it becomes more confusing.

Me in turn ask developers to disable this feature by default for future versions, also write a guide to modify and recompile the old versions of Gedit from source.

Thank you for your notice

Once again I insist: This issue is not RESOLVED FIXED. It is open or won’t fix. It seems that I cannot change the status.

Perhaps this problem is forgotten because of a faulty status? Please update or fix.

Like said in the previous comments, what you want is not the default behavior. You need to:

gsettings set org.gnome.gedit.preferences.editor ensure-trailing-newline false

Or by using dconf-editor

I think what Frank is saying is that the default behavior is wrong.

I happen to agree.  I have already used the workaround, but the default behavior should never have been changed to begin with.

We all know what the default behavior is.  We are saying that's not what it *should be*.

We shouldn't need to play gsettings games to work around behavior that is ill-conceived to begin with.

Please refer to my comment #c13 regarding the Principle of Least Astonishment. Just because some gedit developers can't see any problems, doesn't mean there aren't any.

I can't see the Eiffel Tower out of my lounge window, doesn't mean it doesn't exist.

The default behaviour is wrong.

"In Gedit 3.22, trailing new line is not automatically added any more and is visible"
https://bugzilla.gnome.org/show_bug.cgi?id=698715#c9

Can someone confirm?

(In reply to Bahram Alinezhad from comment #27)
> "In Gedit 3.22, trailing new line is not automatically added any more and is
> visible"

No, that is not true. Tested under Debian testing with Gedit 3.22.0.

Adding a new line is still the default and as sébastien lafargue wrote, it is necessary to change this behaviour with gsettings. Furthermore, the trailing new line is not visible.

On Ubuntu 16.04 with Gedit 3.18.3 the bug seems solved.

I don't remember if I ever had tweaked this with gsettings.

You probably did ;-)
Try
gsettings get org.gnome.gedit.preferences.editor ensure-trailing-newline
gsettings reset org.gnome.gedit.preferences.editor ensure-trailing-newline 
gsettings get org.gnome.gedit.preferences.editor ensure-trailing-newline

So not solved on Ubuntu 16.04, or?

I just realized that Pluma (on Ubuntu 16.04 in version 1.12.2) does not support a similar GSetting.

(In reply to Frank Stähr from comment #30)
> I just realized that Pluma (on Ubuntu 16.04 in version 1.12.2) does not
> support a similar GSetting.

How bad! My preferred distro is "ubuntu mate" which uses pluma form of gedit :-(