Sublime Forum

Make saving newline_at_eof the installation default

#1

It is a general, widely known practical observation that (at least some) people will leave (at least some of) their software preferences alone after installation.

Upon installation currently, the preference is set to false, for whether a newline is ensured at EOF when saving.

This installation default is wreaking a small degree of havoc with programmers using version control software including git, by causing back-and-forth, last line change noise.

Of course, if anyone wants to customize installations to have no newlines at EOF, that’s fine because the problem is their own responsibility, on their own heads. But this shouldn’t be the default, because of the noise problem it causes.

The reasonable and usual practice of software in Unix and elsewhere is to expect, and to maintain, that all lines end with a newline. This includes the final line. For more information, here are two links:

stackoverflow.com/questions/7296 … -a-newline

slashdot.org/comments.pl?sid=165492&cid=13808398

To be more precise, after installation, in Default/Preferences.sublime-settings these statements occur:

// Set to true to ensure the last line of the file ends in a newline
// character when saving
"ensure_newline_at_eof_on_save": false,

This should be changed instead so after installation automatically the statements are:

// Set to false to ensure the last line of the file does not end in a newline
// character when saving
“ensure_newline_at_eof_on_save”: true,

Further, the editor must not display a new empty line after saving as it does now when this preference is set to true. This even though there is a final newline.

This may be because the editor may be treating newlines erroneously as line separators and not correctly as line terminators. This possibility is described in the links above.

2 Likes
How to disable adding end of file newline in ST3?
#2

[quote=“MarkDBlackwell”]
Further, the editor must not display a new empty line after saving as it does now when this preference is set to true. This even though there is a final newline.

This may be because the editor may be treating newlines erroneously as line separators and not correctly as line terminators. This possibility is described in the links above.[/quote]

I would like to vote for this feature as well.

1 Like
#3

This should be the default. Please make it so. I hate having to keep pointing my developers at this thread.

0 Likes
#4

In fact, this thread wouldn’t exist if this default were set correctly.

0 Likes
#5

Another vote for this, it really should be on by default.

1 Like
#6

I’m unsure about this.

Without the setting set, you can still explicitly add a newline if you so desire, and unless yout actually touch the end of a file the editor would leave newline-at-eof or not alone.

If the setting was enabled by default, all changes anywhere in the file would cause it to be saved with a newline and there is no way to undo that, except for removing the setting before saving (or using another editor). In that sense, the more conservative approach would be friendlier and allow for more opportunities.

Here’s another suggestion: Do it like with indentation and add functionality to auto-detect whether the file had a newline at eof when it was opened, and then preserve that when saving. Make it disableable and still allow for a default setting for new files. And finally it could be added to the status bar (toggleable like encoding and line endings).

0 Likes
#7

Sublime Text currently works like every other graphical text editor, except most have no equivalent of ensure_newline_at_eof_on_save: true at all.

Changing the default would cause nothing but confusion for the majority of users.

0 Likes
#8

What about determining the “default” individually for each file though? Indentation and line endings are detected as well, by default at least.

I agree that making "ensure_newline_at_eof_on_save": true the default is wrong, but that way it would still solve the problem mentioned in OP.

0 Likes
#9

@FichteFoll, if you think “true” is wrong, that implies that “false” is correct.

POSIX says that text files are terminated by a newline. I don’t quite understand why this should not be the default?

At my $dayjob, sublime users are the only ones that I have to go tell, “fix your editor” because they all have this default set this way.

Newlines are not Line Separators. They are Line Terminators.

0 Likes
#10

Here you go:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

> 3.206 Line

> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

POSIX says that lines should be terminated with newlines. Sublime text is one of the few editors that gets this wrong by default.

0 Likes
#11

At my $dayjob, sublime users are the only ones that I have to go tell, “fix your editor” because they all have this default set this way.

Agreed

0 Likes
#12

Oh the time I have wasted on this. What a productivity killer!
All lines need an EOL or bad stuff happens.

0 Likes
#13

Exactly this. Over the years it’s become second nature to me to manually add a new line to files, but I do forget sometimes. And as mentioned, a lot of people aren’t even aware of this so this is a frequent annoyance with git.

I think the default should be like vim - automatically add a new line (when it’s missing, except for empty files) and more importantly, do not display it in the editor. I just tried "ensure_newline_at_eof_on_save": true and its behaviour just looks/feels weird.

At a bare minimum add something like "hide_newline_at_eof": true or something to go along with the aforementioned setting.

0 Likes
#14

I personally prefer "ensure_newline_at_eof_on_save": true as well, but honestly, is it so painful to modify a single setting in Preferences.sublime-settings in an editor which propably needs hundreds of tweaks to feel like your own?

I don’t think an editor should manipulate file content upon saving by default.

3 Likes
#15

Not at all, if this option did exist.

0 Likes
#16

I prefer the notion of seeing in the editor exactly what the content of the file appears as on disk. There’s no confusion over whether you’re working with a file with a trailing newline if you can see that there’s a trailing newline.

Applying such information elsewhere (say for example the status bar) is suboptimal because it’s a lot smaller than the text and draws less attention. It’s also possible to work with it turned off, in which case you’d never be able to tell.

0 Likes