search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.23k stars 28.56k forks source link

Trimming final newline is not POSIX standards compliant #141169

Open laurivosandi opened 2 years ago

laurivosandi commented 2 years ago

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

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.

Screenshot from 2022-01-21 19-23-19

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 commented 2 years ago

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

laurivosandi commented 2 years ago

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

jtagcat commented 2 years ago

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:

edit: quick mockup v2: image

tanhakabir commented 2 years ago

@alexdima thoughts?

tanhakabir commented 2 years ago

Sorry duplicate of https://github.com/microsoft/vscode/issues/35181

laurivosandi commented 2 years ago

The default behaviour suggested by @alexdima in https://github.com/microsoft/vscode/issues/35181#issuecomment-332802667 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 commented 2 years ago

The history is slightly more complicated:

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.

lattwood commented 1 year ago

@alexdima what about POSIX macOS?

While changing the default may be unexpected for some users who are accustomed to working around the lack of newline at the end, they're literally working around a bug. 😂

This kinda smells of the emacs-spacebar xkcd. https://xkcd.com/1172/

edit: I checked the Wikipedia article on POSIX.

This has become a bit of a recurring issue everywhere I've worked. People that use vim/emacs/sublime/IntelliJ end up producing POSIX compliant files, but the folks using VSCode don't, and they have to be reminded every pull request. While developers should be comfortable configuring their tools, they should come with sane defaults.

Edit 2: on further reflection, anyone who needs to produce a file that doesn’t end in a newline knows they need to, but everyone should be creating files that end with a newline by default. This came after reading @laurivosandi’s comment below.

laurivosandi commented 1 year ago

I still think it's completely bonkers that on Windows these newlines get trimmed --- git complains, GitHub complains. People have to add idiotic linters into their CI/CD pipelines to prevent developers pushing this nonsense.

Why does VSCode have to be special? Microsoft says it loves Linux yet at the same you keep fighting against POSIX standards which is a cornerstone for all Unix-like systems

alexdima commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 3 weeks ago

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: