Spuriously changes line endings in VS Code Insiders v1.3.0

[wardbell]

I'm using the insiders edition.

Editorconfig changes the line ending of every file I open. Driving me crazy with git.

How do I know? Does it when editorconfig extension is installed. Doesn't when I remove it.

No such problem in regular VS Code.

[jednano]

Sounds like either your .editorconfig file has the wrong settings for the files you are opening or you've checked out files with Git's autocrlf=true. Either way, I don't believe the issue is with the plugin, as it's working as expected by setting your line endings to whatever setting you have in .editorconfig.

[jednano]

My adivce is to do the following in your project:

git config core.autocrlf false
git rm --cached -r .
git reset --hard

[jednano]

Related, #46

[wardbell]

At least you have confirmed (by way of #46 and #26) what was a mystery: the combination of changes to this extension and to VS Code (insiders for now) "makes a file dirty by simply opening it".

IMO, an editor should not change a file until I change that file. That VS Code (or this extension or any tool) should "nanny" me by "fixing my file" w/o permission ... is revolting.

To whom do I complain? Is it within your power to offer an option/setting that disables this "feature" ... that makes no changes until I do?

I don't know why you'd think that I have the wrong .editconfig setting. I haven't touched it since our team settled on end_of_line = lf

As for changing the git config to autocrlf = false ... there is much confusion on that score. I've seen arguments for both settings. Whatever installer I last used recommended true and it has been true on my machines for years without incident.

I'm really torn. I like this editorconfig extension. But I can't afford the git chaos and I work on a team (what a concept) that strives to standardize on many things including line endings and git behavior so I can't go my own way on those settings.

OTOH, team members work on Macs and PCs using a combination of editors. I can't change that and wouldn't want to.

I'll have to do without your extension until this is resolved. I wonder how many others will be obliged to do the same when the insiders edition becomes official.

You may want to get in front of that!

[jednano]

@wardbell I made no assumptions that your .editorconfig file was incorrect. I was only deducing that there are only two scenarios I can think of that would explain your issue (A or B) and it turns out that scenario B, that of core.autocrlf=true is perhaps the winner?

Now, I know, perhaps better than anyone the stresses of working on teams with mixed environments, both open source and private and these issues and arguments come up time and time again. It's the reason I joined the EditorConfig Team, so all the empathy in the world for your situation.

Unlike your project, my recent team members were unwilling to introduce a .gitattributes file to the project, because, the argument was that "in no point in time should Git be changing the line endings of the project." I guess that's the question that I would pose to you – if anything should be "automatically" changing your line endings, should it be Git or your editor? If you had to choose? You say that the editor fixing your file w/o your permission is revolting, but the next guy will say the same thing of Git. Which one is right? Does it matter? You can't make everyone happy, that's for sure.

Fortunately, for you, Git does have a way to edit this setting and it's how I instructed above. I've been forced to use it myself and it's quite painless to do so, as long as you have an EditorConfig plugin in your editor keeping your line endings in sync w/ the project's .editorconfig file.

That said, I could or you could add a feature to this plugin that reads, perhaps, an additional setting unsupported by EditorConfig, but exclusive to this vscode plugin. I'm not sure what that setting would be named, but it could give you what you want in terms of disabling the feature. I'm open to having a discussion about that. If we still don't come to an agreement, you can always fork the project. You have many options here.

Lastly, I want you to consider the possibility that your issue is actually not with this plugin at all, per se, but with vscode's setEndOfLine method, which not only "sets" your end of line setting, but changes the file in the process! This is the only mechanism that vscode exposes to me, the plugin developer, so who is to blame? Would you argue that, perhaps, vscode should not change your existing line endings when you change your end of line setting? That might be a more relevant discussion and you are free to open a vscode issue to this point. Acknowledging the fact that the vscode team has adopted this philosophy with line endings, however, I simply implemented the plugin with the same philosophy (not that I had a choice). Would you rather the plugin have no support for the end_of_line setting at all? Because, at this point, it looks like you can't have both. At least, not within the bounds of the vscode extension API.

[jednano]

There is another option if you want to turn off the end_of_line feature. Just remove the setting from your .editorconfig file! You can add .editorconfig to your global .gitignore and never commit the change. Problem solved. Unless, however, you were expecting the end_of_line setting to be supported in some other way. If that's the case, I'm afraid you're out of luck here. The vscode extension API is just not that flexible. In fact, even without the API, if you were manually to change your line ending setting in a file, notice that vscode changes the whole file!

[wardbell]

Yes. I understand. Sorry about that. We will all have to take it up with the VS Code team. Maybe reference this thread?

I just learned that the same behavior appears in regular VS Code without the warning.

Meanwhile, you have this thread to reference when others stumble into it.

Thanks for a great product, BTW. I regret that I neglected to mention that earlier. Being an OSS author myself I realize how thankless it can seem.

[jednano]

Thanks.

[jednano]

FWIW, the core.autocrlf=true setting and EditorConfig have never been compatible, from what I've seen. Even if it worked the way you suggest, you'll be creating a file with mixed line endings as you edit it. Git will spit out a bunch of warnings about line endings being changed and it's just not an ideal experience all around. I've been through this hell many times before, but not any more, because I now set git config core autocrlf false --system and rely on EditorConfig plugins to keep me in sync. This strategy, in no way, "goes your own way" against your team's guidelines. You can always play with your local Git settings.

[jednano]

Also, @wardbell, I have to say that I agree w/ the vscode implementation of ensuring a file is not saved with mixed line endings. What you are proposing would allow people to save files with mixed line endings and I think that makes no sense. You can always review a GitHub pull request with ?w=1 in the query string to ignore whitespace changes. It makes the diffs a lot easier to read in cases like these.

[wardbell]

Oh I agree with you about saving with ONE kind of line ending.

That is NOT my issue. My issue is that VS Code should make no changes to a file until I make at least one change myself. No matter how bad the file ... leave it alone until I do something.

THAT ... and that alone ... is my entire complaint.

[jednano]

I think you and I can both agree on that argument.

[Bigous]

Hi @jedmao It seems to me that it's an extension problem, because I have no problem now that I removed the extension.

[jednano]

@Bigous did you read this thread? It's definitely the extension, because it's entirely intentional.

[Bigous]

Sorry. My bad.

[jednano]

@wardbell fixed it properly in #116, published as v0.6.1.