editorconfig: Remove unnecessary rules #433
Conversation
None of these rules are needed for Visual Studio and these also do not stem from any defaults/templates of VS.
|
This might also solve some of the problems which @JunielKatarn is having. It should further avoid unrelated whitespace changes and end-of-file changes in future PRs. |
There was a problem hiding this comment.
Right. The crlf there, in combination with not using autocrlf setting is probably causing part of the problems @JunielKatarn has.
He's working on Linux and using a different IDE (Linux because he said it and different IDE because there's no VS for Linux). |
|
If i had to guess he is using Rider. |
|
Since he appears to be affiliated with MS in some form, a very steep speculation would be a secret prototype of a "VS for Linux". It's the most requested topic of all times on the MS Dev Community site (officially rejected though). That would explain why he doesn't tell (not allowed). ;-) |
|
But Microsoft has its own version of this library. I don't think he'd bother with us in a work context. |
I don't mean he works on it, it would be about dog-feeding (letting employees from different projects use it for testing). |
|
Hi! I'm currently out of town and away from keyboard, so haven't had time to review feedback on my PR nor look into this discussion, but notifications show I've been alluded a few times so I'll post some clarifications in my next reply... |
|
In case there's something you wouldn't like to see written here, just let me known and I'll delete it. |
|
Let me start saying I do have issues with this PR. Unless we don't want to use an editor helper tool (i.e. EditorConfig) at all and let whatever formatting issues and potential conflicts happen, we shouldn't drop the whitespace trimming rule. Now, into the mentions:
Partially. It all comes down to that line endings we want for what files.
Not exactly. It's only disabling AUTCRLF that induced the huge diffs. This was intentional (I intended to make VS-specific project files CRLF in the repository as opposed to LF). Again, won't go further into it here.
macOS to be specific, but the same semantics apply to Linux.
Happy to share any further details.
|
I am indeed affiliated with MS in some form :)
I wish!
Sorry if I missed any direct questions on this regard. I was very sporadically available this week. |
| # Xml project files | ||
| [*.{config,csproj,njsproj,targets,vcxitems,vcxproj,vcxproj.filters}] | ||
| indent_size = 2 | ||
| end_of_line = crlf | ||
| insert_final_newline = false |
There was a problem hiding this comment.
This will cause EditorConfig-enabled editors to insert a newline, where Visual Studio trims such newlines when modifying those types of files.
It will cause on and off final newline diffs depending on what tool was used to edit such files.
I strongly recommend to keep this one.
To reiterate, it's not about the VS templates only, but the IDE's editing behavior.
There was a problem hiding this comment.
his will cause EditorConfig-enabled editors to insert a newline
No, this is not true. If no rule exists for this in editorconfig, then it's the editor's default behavior coming into play. For most editors it's based on auto-detection or defaults of the editor. The editorconfig spec defines no default for this type of rule, so having no rule at all is the most compatible setting.
where Visual Studio trims such newlines when modifying those types of files.
VS doesn't trim. It handles mixed line endings transparently without modifying. Only when adding new lines it will choose a line ending style (from auto-detection or VS options settings).
It will cause on and off final newline diffs depending on what tool was used to edit such files.
No. If this rule isn't present, an editor normally doesn't make any change to it. (VS doesn't)
There was a problem hiding this comment.
I think this remark is not about EOL, but about insert_final_newline (newline at end of file). It might be good to keep it as @JunielKatarn suggested.
There was a problem hiding this comment.
If the remark is about newlines at the end of files, then the statement is still incorrect. Visual Studio does not trim any CR or LF at the end of files when editing.
VS leaves everything as is and that's the behavior that we need. On the contrary, the existence of those rules has caused the PR's from @JunielKatarn to include such changes to the end of files which we neither want nor need (assuming that the current state is how we want everything to be).
It's generally important to understand that removing such rules doesn't mean that the opposite would happen. Removing rather means that the editor won't make changes in that regard.
Also important: Visual Studio doesn't need any editorconfig rules at all. It works totally fine without any editorconfig in place.
It's also very unusual to have those EOL and EOF rules when using VS. Never seen that before, it's in none of the templates, nobody does that because there's no need for this in case of VS. It does these things right just out of the box.
There was a problem hiding this comment.
I'd say we should leave insert_final_newline = false in. These are specific VS formats. VS never adds final new lines and removes them when found. It is safe and reasonable to leave this setting in the editorconfig, so other code editors won't accidentially insert final new lines when it is their default.
The reason for removing it is specifically about your submissions which are containing those whitespace changes which don't belong into commits/PRs with functional changes because the whitespace changes are distracting from the actual changes (like I and @lukasf said in response to your PR). Now, I don't know VSCode well enough regarding .editorconfig behavior, but on 2 or 3 occasions, you mentioned that your editor would apply editorconfig rules to the whole file when saving a file. And that's a real problem, because it means that you aren't easily able to work in a way that you can commit functional changes which do not include editorconfig-based changes to lines which don't carry any functional change. Visual Studio is very different here: It applies editorconfig rules only to the lines which you are actually editing and doesn't apply those rules to any other line. And it applies those rules "live" while editing, not on save. Now for the line endings: I think we are all good about the autocrlf setting at the Git side. You have it false on Linux and true on Windows (at least for this repo) - so that's already perfectly in line with what we all are doing. The second side regarding line endings is the |
Thanks a lot for sharing all this info. This allows to get a better understanding of each others workflow and setup and makes it so much easier to find a good solution which works well for everybody! I'm sure we'll be able to figure something out. |
|
@JunielKatarn - from my research, it appears that VSCode itself does not apply those rules like whitespace trim to all lines when saving. It only applied this to edited lines (just like the real Visual Studio). Can you confirm this? I further read that there's a "Editorconfig for VS Code" extension which causes VS Code to apply rules to all lines when saving - do you have that extension installed? |
|
Oh this one got automatically closed as I merged+deleted the winui branch. Please Create a new PR against the master branch. |
Done: #436 |
None of these rules are needed for Visual Studio and these also do not stem from any defaults/templates of VS.