Option to navigate from an EditorConfig violation in error list to EditorConfig entry that caused violation

[mikadumont]

The option to navigate from an editorconfig violation in the errorlist to the editorconfig entry that has caused the violation is not possible today.

[mavasani]

How will this help the user? I believe better solution is that once user double clicks on the error list entry, they are taken to the violation code and the light bulb has appropriate action(s) to perform all the desired configuration directly, without having to manually edit .editorconfig file. IMO it is not a good experience to take users to a configuration file. The assumption her is that user cares about contents of editorconfig file, which is just implementation details. IMO, the best experience involves user able to configure everything without leaving the editor - as a developer I never wish to look at config files, but want UX to enable me to edit it behind the scenes.

[jmarolf]

The assumption here is that user cares about contents of editorconfig file, which is just implementation details.

I think that is the crux of this issue :) Users have asked to learn about how to edit or modify their .editorconfig and our answer is "don't do that think of it as a binary blob".

If we really feel that way, then we should build a UI on top of it so that people can actually interact with it.

If, instead, we think .editorconfigfiles are supposed to be understandable in their own right then we should provide some way for users to understand the relationship between what is in their .editorconfig files contents and the errors/warnings/suggestions they see in the error list.

As I understand it we currently offer to add .editorconfig files as solution items which suggests they are not just implementation details. We also have the excellent code fixes that, for the most part, mean you don't need to think about .editorconfig at all. I think the most important thing is that we are consistent in how we present .editorconfig files.

IMHO: The whole point of .editorconfig files was that they were supposed to be human readable. I severely failed here with naming styles, but the intent remains.

[mavasani]

Agreed @jmarolf. IMO we have 2 choices:

1. No UI, .editorconfig should be human readable and editable: If we go this route, we must make .editorconfig editing a first class experience with language services, intellisense, quick info, diagnostics + code fixes, ease of navigating to documentation etc. similar to our source editing experience.
2. Invest in UX features that make reading or editing .editorconfig redundant. This can be a dedicated UX for just viewing/searching/editing/bulk configuring the .editorconfig (similar to ruleset editor) and/or just improvements to code fixes and UX inside source code editor to enable all of these operations.

I prefer the 2., but I know many folks strongly prefer 1. I believe at the end, we should do what the customers want, because there is significant investment in both of these.