Suppress display of end-of-file newline as blank line

[glen-84]

Currently:

1. Line 1\n
2. \n
3. Line 3\n
4.

What it should be:

1. Line 1\n
2. \n
3. Line 3\n

Row 4 is not considered a line, at least not according to the POSIX definition, so it shouldn't be numbered.

(Atom issue here)

Edit: You might also consider not showing the final line number unless the line is correctly terminated, or, displaying an icon as suggested in this comment. However, this might "upset" certain users, so it should probably be configurable.

[Tyriar]

While I agree that files should have a new line at the end, wouldn't forcing this disallow saving files without the terminating new line character?

[glen-84]

@Tyriar This has no effect on file saving, it's just about the display of line numbers.

[Tyriar]

So the line would still be there, just not the line number?

[glen-84]

Yes, but it's not technically a "line", it's just an area that can receive focus for text entry.

1. Line 1\n
2. \n
3. Line 3\n
   | <-- cursor

[egamma]

@alexandrudima what is your opinion?

[alexdima]

IMHO not rendering the last line number would be confusing, both for users and extension authors, as the last line can be interacted with (e.g. an extension can create edits on it, asking for line count at the API level would return it).

@glen-84 I really like the brief technical explanation from POSIX, but then if I understand correctly:

1. Line 1\n
2. \n
3. Line 3\n
4. This is not a line, but then what is it?

Perhaps the intent of the issue is that the editor should never lead to a situation where a file is not terminated with a newline.

In that case, I would treat the end of file newline in a similar way we treat the UTF8 BOM. The BOM is completely hidden in the model (cannot be interacted with or moved whatsoever) and when the workbench calls model.getValue() it comes. Perhaps the end of file newline can be implemented in a similar way. i.e. "It is not there until saving to disk".

[glen-84]

IMHO not rendering the last line number would be confusing, both for users and extension authors, as the last line can be interacted with ...

I can agree that some users would need to adjust to the change, because they may not be used to it. However, I still feel that it is the correct interpretation, as a line is defined as a series of non-newline characters followed by a newline character, which means that "row" 4 is not a line as defined, but merely a UI affordance (an area that can be focused in order to enter new lines of text).

This is not a line, but then what is it?

A UI area that represents no backing content. No characters, including newlines, are represented. In my understanding, it's essentially not part of the file.

Perhaps the end of file newline can be implemented in a similar way. i.e. "It is not there until saving to disk".

That may be the same way that VIM handles it.

If I enter "Test" into a new file, and save, it saves with a trailing newline:

$ hexdump -c test.txt
0000000   T   e   s   t  \n
0000005

If you open the file, it displays 1L, 5C, and not 2 lines.

This may be an even better way of handling it, so you wouldn't even be able to navigate to the 4th row without hitting enter, which might make more sense and be easier for users to understand. I prefer this actually.

[peterblazejewicz]

Ensure single trailing newline (Atom)

ensure_newline_at_eof_on_save (Sublime)

insert_final_newline (EditorConfig)

As this option is not configurable, there is no easy way to prevent 'No newline at end of file' warnings when using Git in merges (or just when reviewing commits).

[peterblazejewicz]

hm: https://github.com/Microsoft/vscode-editorconfig/issues/18#issue-127438900

[glen-84]

@peterblazejewicz This issue is more about the display (or lack thereof) of the final newline, and not its insertion. i.e. Don't render a numbered blank line at the end of files.

[rightaway]

@glen-84 Agreed. This is how vim does it too.

[croaky]

Coming from Vim, I'm also searching for an option that will automatically save a \n at end of file, but not an "empty line".

More history at https://robots.thoughtbot.com/no-newline-at-end-of-file

[bpasero]

Moving this back to editor, neither I nor the issue creator agrees on the change of summary. I think this should be a setting that only has an impact on how the display behaves, not how the file is saved.

[nathanshelly]

Any update here?

If this is not going to be changed in core is anyone aware of an extension that can prevent display of the last line like no-evil-eol-newline does for Atom?

[brennancheung]

I tried adding the settings files.trimFinalNewlines and files.insertFinalNewline but they don't suppress the display of the final line. They ensure the file as the correct final newline though.

Coming from vim as well, would be nice to have a hideFinalNewline settings. I was deleting them until I got lint errors because I'm not used to seeing them.

[lvella]

This is an annoying issue for people used to the behavior of most Linux text editors. There should be an option to suppress last blank line display.

[sguillia]

Just like vim does by default.

Also it has a binary mode [noeol] that prevents the final newline from being added if the user wants to, for a single file.

[octref]

@alexandrudima Cursor can still move to a line without line number. Is this expected?

If so please remove the verification-found label.

[alexdima]

Yes, that is expected. (we must respect existing API and extensions can place a cursor there, make edits there, etc.).

[alexr00]

This change doesn't affect Windows, correct? Verified with Ubuntu.

[glen-84]

@alexr00 It does if you set editor.renderFinalNewline to false (it's true by default on non-Linux OSs).

[alexr00]

@glen-84, thanks! Verified on Windows too.

[dlech]

it's true by default on non-Linux OSs

Why is it not default true everywhere? I've been adding an extra newline to files all day long without realizing that VS Code changed when I upgraded to 1.32. It took me quite a while before I figured out that could put the cursor on a line with no line number.

[mths0x5f]

I here to say I hated this "breaking" change. I spent a whole day frustrated looking for the correct setting to I'm used to. You shouldn't change something people expect unconsciously to be there without notice.

[s-spindler]

I agree with @dlech and @mths0x5f on this one. Nothing against adding the option for people who want it but the default should be to keep consistent with the old behaviour. Now there are people searching for how to "fix" it and opening tickets like #70344.

[glen-84]

The code in the merged PR returns an empty line number when the line content is an empty string, instead of when it doesn't end with a \n. i.e. The line number technically shouldn't be displayed even when you start typing (only when you hit enter).

Also, shouldn't this be false by default on Mac as well?

Finally, I think that (to make it less confusing for users used to the old behaviour), an optional display character to indicate that the previous line ends with a \n could be helpful.