Open laurivosandi opened 2 years ago
You can turn on the setting files.insertFinalNewline
to always insert a final new line at the end of each file.
This default does not adhere to POSIX standard. People should not take extra steps to be standards compliant.
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:
@alexdima thoughts?
Sorry duplicate of https://github.com/microsoft/vscode/issues/35181
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
The history is slightly more complicated:
editor.renderFinalNewline
and it was by default false on linux and true on all other platforms.editor.renderFinalNewline
to true by default on all platforms via https://github.com/microsoft/vscode/pull/70127But 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 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.
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
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.
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
@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.
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:
Does this issue occur when all extensions are disabled?: Yes
Steps to Reproduce:
cat
to read the fileI 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