New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide option to opt out of line ending normalisation for files #127

Open
ghost opened this Issue Nov 19, 2015 · 6 comments

Comments

Projects
None yet
6 participants
@ghost

ghost commented Nov 19, 2015

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!)

@alexandrudima

This comment has been minimized.

Member

alexandrudima commented Nov 24, 2015

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

This comment has been minimized.

ghost commented Nov 24, 2015

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.

@alexandrudima alexandrudima removed their assignment Dec 8, 2015

@egamma egamma modified the milestone: Backlog Dec 10, 2015

@basarat basarat referenced this issue Feb 18, 2016

Closed

Line endings #13

@sleaze

This comment has been minimized.

sleaze commented Mar 15, 2016

+1 to that!

@matlimatli

This comment has been minimized.

matlimatli commented Oct 19, 2017

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

This comment has been minimized.

XFunc commented Jul 10, 2018

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

This comment has been minimized.

gwax commented Sep 4, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment