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.