Trimming final newline is not POSIX standards compliant

[laurivosandi]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.63.2
• OS Version: Ubuntu 20.04

Steps to Reproduce:

1. Type anything in the editor and save it to a file
2. Run cat to read the file

I am becoming increasingly annoyed by Visual Studio Code users because files are created without final newline.

This results in mangled shell prompt as shown above. In a sane world shell prompt starts on a new line.

Feel free to do this on Windows, but don't bring this madness to Linux and Mac. You're just wasting our time explaining how to turn off trimming and why trimming is bad.

In POSIX line ends with newline:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
and text file consists of 0 or more lines: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403
Hence text file ends with a newline character

[tanhakabir]

You can turn on the setting files.insertFinalNewline to always insert a final new line at the end of each file.

[laurivosandi]

This default does not adhere to POSIX standard. People should not take extra steps to be standards compliant.

[jtagcat]

I am becoming increasingly annoyed by Visual Studio Code users because files are created without final newline.

User wants to get the default changed.

It's not a bad idea, except that files.insertFinalNewline is counter-intuitive at first (feels like the end line is forced).

Instead: what about implementing the option as such:

• make the last line darker (creating depth, and half-greying it out)
• keep it out of all selections (unless explicitly selected and deleted)

edit: quick mockup v2:

[tanhakabir]

@alexdima thoughts?

[tanhakabir]

Sorry duplicate of #35181

[laurivosandi]

The default behaviour suggested by @alexdima in #35181 (comment) is still not implemented

Moreover Git itself will complain if file is added without final newline:

lauri@lauri-x13:~/dingo$ git diff --cached
diff --git a/hello b/hello
new file mode 100644
index 0000000..95d09f2
--- /dev/null
+++ b/hello
@@ -0,0 +1 @@
+hello world
\ No newline at end of file

[alexdima]

The history is slightly more complicated:

• Suppress display of end-of-file newline as blank line #64667 introduced editor.renderFinalNewline and it was by default false on linux and true on all other platforms.
• this shipped as stable!
• but then we got Default value for renderFinalNewline on Linux is bad for conditioned users #70126 which complained that long-time users which got used to the previous behavior were now confused by the changed default and then we turned editor.renderFinalNewline to true by default on all platforms via Make the default value of renderFinalNewline the same on all platforms #70127

But I agree that the current situation is not good. I start to think editor.renderFinalNewline should be slightly changed to render a dimmed line number, as @jtagcat suggests here, and at the same time changing the default again to false on linux and maybe also on macOS.

[alexdima]

I just wanted to remind everyone that VS Code offers two settings: files.insertFinalNewline and editor.renderFinalNewline that I believe can be used effectively to get the desired behavior. Please let me know if that's not the case. In all projects where you collaborate with VS Code users, you can define these settings in .vscode/settings.json. This is the same mechanism you would need to define editor.insertSpaces, editor.tabSize, files.trimTrailingWhitespace, etc.

Regarding linters, I personally think those are a good idea in any case, especially in projects involving more developers, since linters allow to enforce a min-bar in terms of code quality, regardless of the tool used to contribute. Linters are useful to enforce other things as well, like copyright headers, consistent line endings, consistent indentation characters, banning dangerous confusable Unicode characters, etc.

IMHO, there is no need to change the defaults to ensure a final EOL sequence in all files. We need to consider all of our VS Code users, and such a change would be disruptive for the majority of them.

[lattwood]

Consider this, @alexdima this is disruptive enough I’m not a VSCode user and I’m commenting on an issue.

In a collaborative environment the disruption caused by VSCode ending files in an incomplete line is several orders of magnitude more than changing this default.

Git complains, github complains, most other tools call out a missing new line at the end of a file and/or put a newline there automatically.

Once again a Microsoft tool is choosing incompatibility over interoperability, some things change while others stay the same.

Edit: stackoverflow link explaining why on POSIX systems you should write POSIX files https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline/729795#729795

[4nd3r]

@alexdima what is blocking fixing this issue? I see open PR for Linux and Mac, but we still want to wreak havoc on Windows? Working in a diverse team with all possible operating systems under the sun, this just creates misery to the point where Windows users, building for Linux, consider ending new-line just a formatting issue and not the standard practice which should go without even thinking about it.

[remcohaszing]

I don’t think swapping the default of files.insertFinalNewline is disruptive at all. IMO keeping it false by default is the disruptive thing to do. As has been pointed out in other comments, other tools expect text files to have final newlines, including cat, Git, and GitHub.

Editor settings such as .idea or .vscode should not be checked into version control, so that’s not a viable option. Anyone is free to have a different opinion on this, but a lot of people share my opinion.

Teaching all contributors to enable files.insertFinalNewline because VSCode has poor defaults is also not a good option.

Linters such as Prettier and ESLint are indeed a useful tool to enforce the use of final newlines. However, not all file formats are supported by the linters used. Also not all projects use them. I especially notice files in VSCode related repositories tend to lack trailing newlines, but not consistently.

The invalid default often leads to unwanted diffs alternating the use of final newlines, where one author has configured their editor correctly, and the next author uses bad defaults.

The situation for JSON files is even worse than for other files. Not only will VSCode not add a final newline, it will remove existing final newlines.

Some related issues:

• JSON formatter removes newline at end of file #176246
• insertFinalNewline should default to true vscode-json-languageservice#203
• Add final newlines vscode-languageserver-node#1327

[mohag]

I just wanted to remind everyone that VS Code offers two settings: files.insertFinalNewline and editor.renderFinalNewline that I believe can be used effectively to get the desired behavior. Please let me know if that's not the case. In all projects where you collaborate with VS Code users, you can define these settings in .vscode/settings.json. This is the same mechanism you would need to define editor.insertSpaces, editor.tabSize, files.trimTrailingWhitespace, etc.

The issue is that in *nix text files, "newline" (\n) is a line terminator, while on Windows "newline" (\r\n) is a line separator - they should be treated differently. In a CRLF file a "newline" at the end is a blank line, while the lack of one in a POSIX text file is an incomplete line...

Those settings seems to change the handling of "newline" characters for all text files... (So you either end up with an extra line in Windows files or with an invalid final line in POSIX files)