Gedit adding a newline at the end of file should be configurable

[Garbin Huang]

Binary package hint: gedit

Ggedit auto adds a newline at the end of file.I hope it can be configurable.

I'm not a c/c++ developer, i'm php developer. but I use gedit for my php developing. Gedit auto adds a new line at the end of file, which will cause a problem when the program runs. I hope this action can be configurable. thanks~!

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/gedit
Package: gedit 2.24.2-0ubuntu1
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=zh_CN.UTF-8
 SHELL=/bin/bash
SourcePackage: gedit
Uname: Linux 2.6.27-14-generic i686

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

[Sebastien Bacher (seb128)]

that's not a bug but a design decision, new line chars are useful for some command line tools and editor and that's something many editors are doing, having an option for small similar details would rather confuse users than be useful, if you really need that you should look for an another editor, gedit will stay simple to use for users

[Felipe Hummel (felipehummel)]

I think you should reconsider the new line. It totally crashes PHP redirects. PHP looks the new line as text. So when you try to send new header, it has already been sent because of the tiny \n.

[Raf Schietekat (raf-schietekat)]

I have reraised this issue because this disturbing misfeature has always bugged me no end with vi. The appropriate behaviour is to let the user confirm that the file has no final newline, with a checkbox to always silently add one (which I will most definitely never use!), and a preferences setting (so I can deactive it if necessary). Now there is no indication of whether a final newline is present (should we cat the file on a terminal, perhaps?), and no possibility to create a file without one (and I was so happy to have gedit for that). Least surprise has always been an element of a good user interface, and this is both surprising and extremely annoying. Please don't patronise your users by dismissing a well-founded concern.

[Sebastien Bacher (seb128)]

The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[Raf Schietekat (raf-schietekat)]

Another reason why the behaviour in the previous LTS 6.06 was appropriate and the vi-style behaviour in the current LTS 8.04 not: consistency. If I have a number of lines and want to move one, I select it by dragging from the beginning of the line to the beginning of the next line, cut, and then paste somewhere else, or do the same by dragging. If I decide to paste the line at the end of the file, I have to go to the end of the file, hit enter, paste, and then not forget to remove the pasted newline to avoid a double newline at the end of the file, unless perhaps if I know at the time of selecting and cutting the line that I'll be moving it to the end (select from end of previous line to end of line to be moved), unless it's the first line (no previous line to use as the start of the selection, which becomes especially awkward for drag-and-drop, because you then have to make sure to break the moved line in the correct place). Similar problems occur when moving the last line of the file. It's just all wrong... please roll this change back.

[Lesmana Zimmer (lesmana)]

i did some searching in the gnome bugzilla and found this

http://bugzilla.gnome.org/show_bug.cgi?id=95676

basically it is the opposite of this bug report, instead of one extra newline there is a line missing. maybe the patch for that bug caused this bug?

[Raf Schietekat (raf-schietekat)]

Oh yes, now empty files have also become an unknown concept. To create one, or empty out an existing file, you have to instead open a shell and do something like "echo -n > file". This is indeed most annoying!

And why (see #8) should a deficiency in an entirely different program on Red Hat affect gedit everywhere?

I don't care to think what mistakes are being made elsewhere if protests about something as utterly trivial as this are so obstinately being ignored, let alone the fact that someone thought it was a good idea to begin with and managed to have his change accepted...

[Chris Coulson (chrisccoulson)]

Would you mind forwarding this upstream to https://wiki.ubuntu.com/Bugs/Upstream/GNOME ?

Thanks

[Sebastien Bacher (seb128)]

did you open a GNOME bug?

[Garbin Huang (garbinhuang)]

No yet. maybe I will consider your suggestion. thank you!

On Fri, Oct 23, 2009 at 6:13 AM, Sebastien Bacher <email address hidden> wrote:

> did you open a GNOME bug?
>
> --
> gedit add a newline at the end of file.I hope it can be config
> https://bugs.launchpad.net/bugs/379367
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “gedit” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: gedit
>
> gedit auto add a newline at the end of file.I hope it can be config
>
> I'm not a c/c++ developer, i'm php developer. but I use gedit for my php
> developing. gedit auto add a new line at the end of file, It's will cause a
> problem when my programm running. I hope this action can be config. thanks~!
>
> ProblemType: Bug
> Architecture: i386
> DistroRelease: Ubuntu 8.10
> ExecutablePath: /usr/bin/gedit
> Package: gedit 2.24.2-0ubuntu1
> ProcEnviron:
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> LANG=zh_CN.UTF-8
> SHELL=/bin/bash
> SourcePackage: gedit
> Uname: Linux 2.6.27-14-generic i686
>

[Anton E. Gavrilov (tonik)]

I agree forcing a newline at end of file is a bad design decision and I would like it reverted.

It bit me today when working with php files.

[lowang (przemyslaw-wroblewski)]

as a workaround I can recommend installing following plugin:

http://github.com/dinkel/gedit-whitespace-remover/

[David Felix (felix-davidj)]

This issue occurs for me as well. I'd like to say that although SOME may consider this a "design decision" or a feature, the fact that gedit does this silently, and has no options to turn this behavior off is very annoying. Neither notepad++ (windows) nor Kate generate a newline at the end of file and I've never once experienced a problem, in fact, that's DESIRABLE.

[papukaija (papukaija)]

Is there any news about this bug? Has someone affected by this bug sent the report upstream? Could you tell us the bug number, so we can add a bugwatch that will inform us about its status.? Thanks in advance.

[Matt Kantor (mkantor1)]

Sorry to bump this very old bug, but I found it very hard to find any help on this issue, so I wanted to post some more information here.

An upstream bug covering this issue can be found at <https://bugzilla.gnome.org/show_bug.cgi?id=625955>.

@lowang: That plugin does not resolve the issue. It removes user-placed whitespace, but not the magical hidden newline at the end of the file. Does a plugin exist which can do this? Is such a thing even possible, given how Gedit inserts it?

[Jails (sjaillet)]

I don't understand why this behavior is still imposed to the community. A simple option or plugin would allow everyone to enjoy gedit. the argument that "having an option for small similar details would rather confuse users than be useful ... gedit will stay simple to use for users" doesn't make sense for de following reasons :
- Silently adding a newline at the end of the file is not a "detail" for me.
- The Gedit syntax highlighting and features in general make it usefull for a wide audience and programmers too.
- Gedit has dozens of "expert" plugins but none can be done for this issue since the newline is always added at the end.

Users should have the choice to be able to configure Gedit to make it save exactly what they write, no more no less.

[John Beatty (jby601)]

I came across this bug while trying to understand bash. If I do

$ printf "%s$IFS" > out.txt

and look at out.txt in gedit, I am quite unaware that $IFS has the newline character as its last character, because gedit thinks "aha, this file already has a newline character as its last character, so I needn't display it". Just to be sure I opened out.txt in hexedit before opening it in gedit. I believe policy should be divorced from mechanism - if I want a newline I should be able to add it myself; and have gedit show whether it's there or not.

Incidentally, in <https://bugzilla.gnome.org/show_bug.cgi?id=625955> Jesse van den Kieboom has provided a patch, but I'm not enough of a linux guru to know how to apply it, and I don't see an entry for it in gconf-editor.

[Ma Hsiao-chun (mahsiaochun)]

Hi, all.

If you are using 12.04 or 12.10 (other versions not tested), you can set the behavior already.

1. Run dconf Editor (dconf-editor)
2. Go to /org/gnome/gedit/preferences/editor
3. Uncheck ensure-trailing-newline if you don't want automatically added newline.

[papukaija (papukaija)]

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

[John Beatty (jby601)]

Thank you Ma Xiaojun, I shall have to upgrade.

[Vaclav Petras (wenzeslaus)]

Can someone clarify the status of this bug report? I can see Invalid & Fix Released seems really strange and there is no explanation how it was fixed (sorry, I'm not able to understand the proposed patches).

Is there any other way how to changed it except for:

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

or its GUI equivalent? Is there a option in Gedit preferences for this, so that it is visible to all users without searching online? Was the design decision reconsidered according the confusion it creates? See for example:

http://stackoverflow.com/questions/3056740/gedit-adds-line-at-end-of-page

Was the fact that that most of Gedit users are developers which want to take care about these things them selves or see the current state in the file? What is the current default?

Thank you, I would say that explanations at the end of tickets avoids opening duplicate tickets in the future.

[papukaija (papukaija)]

This bug is fixed in Ubuntu 12.04 Precise Pangolin and newer (earlier releases are no longer supported expect for some server releases). This bug is only marked invalid for Ubuntu because it is unknown in which release this bug was fixed. The fix released status for the non-Ubuntu Gedit means that this bug is also fixed by Gedit's developers (Gnome).

There is no GUI option in Gedit itself, but you can use the Dconf Editor which is fully graphical. You may need to install it first (eg. from the Software Centre) if you cannot find it from your system's menus. Once you have opened Dconf Editor, navigate to the /org/gnome/gedit/preferences/editor folder and uncheck the "ensure-trailing-newline" option. The default value for this option is checked; ie. to add a new line to the file's end.

I hope this answers your questions. Please do not hesitate to ask for further help or clarification about this bug. Thanks.

[Edgar Bonet (linu7)]

To those who think the default behavior is a "deficiency" or a "bad
design decision": it is neither. It is the only correct behavior when
dealing with text files. It is not a matter of "simple" vs. "complex"
editors either: it is a matter of Windows vs. Unix text format.

In the Windows world, text files use CRLF as line _separators_. In the
Unix world, text files use LF (newline) as line _terminators_. This is
an important distinction, and it implies that a text file _must_ end
with a newline character. Otherwise it's not a valid text file.

See "Why should text files end with a newline?":
https://stackoverflow.com/questions/729692

The argument about this causing problems with PHP is moot. PHP accepts
"?>\n" as a valid end-of-code delimiter: it doesn't output the final
"\n". Proof:

    $ echo '<?php echo "foo"; ?>' > foo.php
    $ hd foo.php # Notice the final 0a = LF
    00000000 3c 3f 70 68 70 20 65 63 68 6f 20 22 66 6f 6f 22 |<?php echo "foo"|
    00000010 3b 20 3f 3e 0a |; ?>.|
    00000015
    $ php foo.php | hd # Notice the _lack_ of final LF
    00000000 66 6f 6f |foo|
    00000003
    $

Note also that in vim you can save a file with no final newline, but for
this you have to enable "binary" mode, which makes sense because the
file you are saving is no longer a text file.