Provide option to opt out of line ending normalisation for files

[ghost]

Upon saving a file edited with VS Code, it appears to perform line ending normalisation automatically and without user notification of any sort. Because of this, I've found myself bitten by large diffs in Git (I'm aware you can circumvent this using the -w flag) where a trivial fix to a single line of source code appears to affect a significant proportion of the file, which makes pull requests and reviews for such changes on GitHub a pain to sift through. Then again, I guess one could argue why a source file with mixed line endings should stay in version control like that anyway!

Visual Studio Community displays a prompt upon opening a file if it has mixed line endings and lets a user decide whether or not to have it fixed.

Version: 0.10.1

(By the way, great work on open sourcing VS Code too, thanks!)

[alexdima]

The current file model normalizes the line endings as soon as the file is read (i.e. each line does not keep track of its EOL), the model only keeps track of one EOL for the entire file (which is computed on file open as the predominantely used EOL character).

@miqid Before we invest a lot into supporting this, when is it desirable to have a file with code that uses mixed EOL sequences? (i.e. why would you want to have a mixed EOL file at all)

[ghost]

Thanks for the insight @alexandrudima - a bit gutted to hear it won't be a trivial change.

Personally, I don't believe having mixed line endings around is a sane thing at all. Where the normalisation becomes a problem for me is when I need to make small edits in source files part of huge code repositories owned by people (usually in the commercial industry) who are extremely stringent on changes they allow through.

I've instead been using the Atom editor to commit changes to files where line endings aren't normalised as it preserves the original line endings of a while on save.

If it is going to be too much effort, I'm happy for the feature request to be closed off as there are alternatives beyond VS Code.

[sleaze]

+1 to that!

[matlimatli]

This would be important when editing files with a binary payload. Think shellscripts with a built-in binary blob, or data files with a plaintext header part.
For me, it would be OK if I could select a number of file extensions for which no conversions are ever applied.

[XFunc]

Clearly, having mixed line endings in source code files is not sane at all. But this is something you often have to deal with in cross-platform development environments (Windows developers not aware at all of the EOL they are inserting in source code files, since the very beginning of the project).
Having the possibility to choose or not EOL normalization would then be great for such scenarios.

Thanks

[gwax]

In my case, I would like to edit a .gitignore file with \n for line endings that contains an entry to ignore OSX Icon\r\r files. These are the only \r in the entire file and stripping them will break the file's behavior.

[smlam]

EOL normalization should be optional feature and off by default.
We do not expect file editor will change non-edited code without user conscious.

Thanks

[shreyasminocha]

@gwax Icon? works for me

[gwax]

@shreyasminocha Yes, Icon? works when people are aware of the issue and remember to watch out for it. The risk is that a .gitignore file exists with a Icon\r\r entry and is edited by someone that does not know to watch out for line ending normalization.

That person comes along, adds an entry to the .gitignore, doesn't see the change from Icon\r\r\n to Icon\r\n or Icon\n, commits it and breaks the file for other people.

The crux of the issue is that the editor is making changes to the rest of the file without warning or explicit configuration request.

Compare to the behavior of the (similar) "Trim Trailing Whitespace". The feature also potentially edits untouched lines of a file but must be enabled by configuration before it will modify anything.

[NoK-Poijes]

Is there a way to turn off this line ending normalization?

[renehamburger]

I've come across another scenario where the automatic normalisation of line endings is not desirable: an SQL export, which contains LF as the main line ending at the end of each row, but in my case also CRLF line endings within fields that contain multi-line text.
I'm able to align these in my case, but I think this example shows that there are valid cases where line endings should not be automatically normalised.

[nour-s]

I have the exact issue when making a pull request. I get surprised that the whole file is changed when I just changed one line!
What makes it even worse, is that I only know that after I create the pull request and someone else review it !

I work on both Mac and Windows, and I believe switching between them is what makes this problem.
Any way to disable this?

[mathias-a-la-basse]

Please fix this issue since this is not just to be more comfortable, this is a mandatory feature of any modern editor:

how do you work with XML having CDATA entries with different lineendings than the surrounding XML document??

I just can't edit such a file in VSCode, since it will thrash the CDATA parts, or the XML part.....
I guess I should stick to Notepad++.....

Please, there should be a mode like in Notepad++:

1. VSCode try to guess the default line ending --> show CRLF / LF.
2. The default is only used when typing ENTER key
3. there is no other alteration of the file
4. VSCode can display the true line endings character (realy this should be core feature, not an extension!), and show up with Toggle Controle Character (because they are, really)
5. the user can choose to normalize the file OR normalize the selection

[chevcast]

Completely agree with the above. This should be a core feature. I shouldn't have to install an extension to see the line endings either. I expected the show control characters feature to show line endings but it did not and I had to hunt for an extension.

[JoeHartzell]

I also would like to agree with the above statements. We for one develop on windows but then use linux docker containers. If we have to write shell scripts for docker using vscode, it usually causes issues. This is especially true if a developer tries to just modify one line, they have to be aware and make sure they set the line ending back to LF.

[sleaze]

Can't believe this still isn't fixed!

I decided to move on to Spacemacs and haven't looked back..

[gwax]

For those that are still dealing with this, I have that the EditorConfig plugin provides an easy workaround for the problem: https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig

You can use your .editorconfig files to define a project wide configuration and to specify overrides. VSCode will then obey the line ending configuration managed by EditorConfig.

[finn-matti]

@gwax This will not help when dealing with mixed line endings, right?

[Leif-W]

@gwax @finn-matti I'm using EditorConfig already. The end_of_line option forces one line ending of the three cr, lf, or crlf, which doesn't help with a mixed line ending character. Besides the above three, you can set it to unset, but that just uses the default which is one of the 3. Also, you can set to nothing end_of_line = , but that is not a valid key value pair, so it is ignored, and uses the default.

It'd be nice to selectively (per-file or file-pattern, or directory), be able to simply disable all end-of-line mangling, and trust that the developer knows what they are doing and have a valid reason, in both VSCode and extensions like EditorConfig or Prettier.

Unfortunately, the only option is to not edit those files with VSCode, either using Vim or NotePad++ or some other basic editor, or specify escape sequences in a programming language, treat those special files as templates, and 'build' the text file. Having a text editor that hinders editing a text file and forces you to write code to build it, is pretty absurd.

Luckily for me, it's an edge case for now, encountered once or more per project, only if I use source control and allow Apple/macOS contributors but prevent Icon cruft in repo. (<sarcasm>Who needs source control anyways! Nobody uses macOS for development either, it never caught on. I like cruft.</sarcasm>) But what if it's not such an edge case for others?

[wolfoo2931]

+1
The current behavior is annoying if you have to contribute to a repo that has a mixed file ending. It just messes with the diff and makes a review of the PR much harder because you see a lot of unrelated red/green lines.

[shawn-eary]

Clearly, having mixed line endings in source code files is not sane at all. But this is something you often have to deal with in cross-platform development environments (Windows developers not aware at all of the EOL they are inserting in source code files, since the very beginning of the project). Having the possibility to choose or not EOL normalization would then be great for such scenarios.

Thanks

I sometimes run into this issue at my day job. We have at least one MS Windows project in which developers contribute via heterogeneous tools. They don't always set up these tools and/or the Git client to consistently handle line endings. For whatever reason, line endings, spaces and tabs often wind up getting "jacked up" or even mixed in the same file thereby creating merge conflicts and visual noise. Sometimes I wind up using Notepad++ just to correctly see the line endings and whitespace; unfortunately, Notepad++ is an MS Windows only program even if there is apparently a Snap package out that makes it easy to run Notepad++ via Wine. I think EMACS and vi make it possible to see the line endings and whitespace also to some extent; however, I would rather Visual Studio Code behave more like Notepad++ and do the following:

1. Leave line endings, tabs and spaces alone by default, but give users a menu option to normalize them to Windows, UNIX, or Mac format per request
2. Display line endings, spaces and tabs for each line very clearly

Attached is a picture of what I'm talking about...

BTW: I think Visual Studio (proper) - Not Visual Studio Code actually had a history in the past of jacking up line endings. Between that and the MS Windows client of Git, it seems we have managed to get some seriously jacked up line endings in one of our repos. That causes massive headaches when trying to merge changes among various branches.
https://developercommunity.visualstudio.com/t/mixed-and-inconsistent-line-endings/363894

DISCLAIMER: My comments in this "bug entry" do not represent any current or former supervisors I have. Terms like "jacked up" are not officially endorsed language of my current employer; however, in this particular case, I'm calling it like it is... Furthermore, I reserve the right to solicit job opportunities with employers that feel "jacked up" is an acceptable technical phrase.

[gpnerds]

Unless I'm missing something, shouldn't this be as easy as checking if mixed line endings are detected in the file, prompt the user to either ignore or fix them? The only real case that I can think of is is when this is exactly the intention (fix those wrong line endings and enforce my own) so the prompt would work for people who want to opt out of this behavior and for those who intend to fix the incorrect line endings.

[Prinzhorn]

@gpnerds this issue also tracks this for Monaco (microsoft/monaco-editor#1813, microsoft/monaco-editor#1225, microsoft/monaco-editor#1427). So what you're suggesting does not apply. When working with Monaco I want full control over line endings. Each time a new line is added, e.g. by pressing Enter I want to be in control what needs to happen and also be able to change the line ending for individual lines. I don't really care what level of control VS Code will expose as long as Monaco gives us all the control we can have.

[joyceerhl]

FWIW, I just ran into this editing a pull request in a file that has intentionally mixed line endings in both github.dev and Codespaces--it's unfortunate that there's no way to disable this behavior, and unexpectedly, the builtin diff editor does not tell me about the line ending changes, so I only realized that I'd messed with the line endings when viewing the PR diff on github.com.

If not for this behavior I'd have been able to complete this otherwise very straightforward PR entirely from the github.dev web editor, but as it stands I had to switch to a different editor to undo the line ending changes I'd made (making this the first time in 4 years that I've used an editor other than VS Code).

[Nowaker]

This is super annoying. To keep git history clean and free from cross-branch conflicts, I want to leave the line endings out of a commit. Just change the lines I want to change and that's it. If the current file model normalizes the line endings as soon as the file is read, then clearly this is a wrong model for this use case as VS Code is a development tool.

[nbouvrette]

I have a project where I need to test the behavior of different escape characters and since I was using a static file to organize my tests (with different \r\n characters) I need to edit it with Notepad++ to avoid breaking my tests.

[ishepherd]

Here's a use case for mixed line endings:

We verify our HTTP responses by diffing against "golden" files.

• HTTP response headers standardly have CRLF (per RFCs)
• Then the HTTP response body standardly has LF (if produced by *nix systems)

Please could VS Code be able to edit our "golden" HTTP response files. 🙏

[softorangetech1122]

When is this closing? It's been opened since Nov 18, 2015

[kenlam-hkpc-org]

I need this feature too, and I agree with this reply from mathias-a-la-basse commented on Jun 25, 2019.

Please fix this issue since this is not just to be more comfortable, this is a mandatory feature of any modern editor:

how do you work with XML having CDATA entries with different lineendings than the surrounding XML document??

I just can't edit such a file in VSCode, since it will thrash the CDATA parts, or the XML part..... I guess I should stick to Notepad++.....

Please, there should be a mode like in Notepad++:

1. VSCode try to guess the default line ending --> show CRLF / LF.
2. The default is only used when typing ENTER key
3. there is no other alteration of the file
4. VSCode can display the true line endings character (realy this should be core feature, not an extension!), and show up with Toggle Controle Character (because they are, really)
5. the user can choose to normalize the file OR normalize the selection

[treeswift]

@alexdima > when is it desirable to have a file with code that uses mixed EOL sequences? (i.e. why would you want to have a mixed EOL file at all)

There is a well-known issue with patch. TL;DR upon detecting a CRLF patch file patch would auto-convert it to LF and then fail to apply to a CRLF source file. The only solution that doesn't require tinkering with the build system that calls patch is to keep the patch headers LF and the patch contents CRLF. We currently achieve that by splitting the patch file into headers and bodies, converting the bodies to CRLF and then concatenating the fragments with cat. The process can be automated, but then the developer has to remember that the patch file shouldn't be ever touched by VSCode.

patch can accept a --binary flag suppressing the conversion, but then the line ending uniformity requirement requires us to prepare a separate patch for LF files and another one for CRLF files if they coincide in a single project.

Forking the project is not always an easy option in a corporate environment (licensing etc.), and forking only to normalize the line endings is less likely to be seen as a worthy reason to bother the legal department.

[PSTDylan]

I've been working with .sql files that contain encrypted data and unknowingly causing issues due to this "feature". At the very least, a notification that line endings were normalized upon opening the file would seem warranted. It's been 9 years since this issue was opened. As a dev who has been using VS Code for years, it took this biting me to look it up. No third party extensions appear to support this either. Overall I love this editor, and would like to use it for nearly everything, but now I'm forced to install something like Notepad++ just to work around this one issue.