View.Modified desynch editing .editorconfig

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Note to the 1st line CCP representative: No, I don't have any more information to give you about this. If you need more information you simply have to start using VS to experience this for yourself.

No solid repro, it seems to be stochastic, but frequent enough to warrant an investigation.

• .editorconfig in a Solution.
• Editing C# source file part of a Project in same Solution.
• Opened solution .editorconfig by either double-click or Return. Got hit by the [.editorconfig editor]. Hit F7 to enter text view. Closed the [.editorconfig editor] view.
• Commented out one C# Analyzer severity suppression configuration line. Unknown if I saved .editorconfig at this point.
• Did some editing (using an action enabled using the now commented out analyzer-suppression).
• Swapped back to the .editor config view.
• Ctrl-Z.
• Ctrl-S.

??? VS... not again. *sigh* Ctrl-S, Ctrl-S, Ctrl-S. Nope, still displays as modified.

Note that this was the ONLY display of the error - the asterisk NOT going away on the tab of the View you commanded VS to save. No audio feedback. No big red "Uh-oh, we've gone effed up again". Nothing. That is Bad Design(tm).

My suspicion is as follows:

• The View have its own copy of a Modified flag. This controls whether or not to display the "modified" asterisk trailing the name in the tab. This would be a root cause of such a bug.
• The Document have a Modified flag (here, and ONLY here, is where it belongs).
• Due to bugs in VS, the View.Modified gets out of synch with the Document.Modified.
• When trying to save, the View says "Yup, I'm modified".
• The handler for the Save command tries to save the Document.
• Document responds "Get outta here, I'm not modified".
• Save handler notifies the View with the Microsoft patented "Something went wrong".
• The View, trained to perfection in the art of apathy goes "Oh well, I guess I'll just keep displaying this as modified until the cows go home then".

If that analysis is correct, the root cause should be obvious. The view _shall not (!) _ have its own copy of Modified. It shall ONLY query the Document. Having two separate copies of the same mutable property WILL, sooner or later, desynch.

You already know this from the mess of the disappearing caret, and how you tried to polish the to make it less obvious by synching on a timer - yet the bug is still there, and it still negatively affects your users. Sweeping a under the rug doesn't make it go away, it doesn't hide the smell, it just temporarily hides it from view. From a large enough distance.

Alternatively, some part of VS modified the .editorconfig from underneath the View, but the change due to other bugs in VS didn't propagate to notify the view that "Document has changed".

Whatever the root cause, this is only one of the many bugs involved with editing or trying to edit .editorconfig, whether manually or using the "Configure Severity" popup sub-menu (where it never works if you don't also have .editorconfig already open in VS, and only works 20-50% of the time if you do have it open). You really, really need to work on your quality.

---

Original Comments

Feedback Bot on 12/1/2021, 00:45 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Feedback Bot on 12/1/2021, 10:15 AM:

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2019#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.

---

Original Solutions

(no solutions)

[jmarolf]

duplicate of #54556