roslyn: Pressing Tab key causes unwanted code changes

Please consider this code:

image

Pressing the Tab key while the cursor is positioned immediately after the Class property results in IDE making this change:

image

I have removed all the code snippets for C#:

image

I have chosen to never include snippets:

image

But the IDE refuses to allow me to insert a tab character after the word Class, and instead performs this nonsensical change resulting in broken code.

Furthermore, copying Tab character from elsewhere in IDE and pasting it after the word Class results in this change:

image

That’s right, the code is reformatted (which I didn’t ask for) and Tab character is not inserted (which I did ask for).

If at this point I hit Ctrl+Z, the alignment will be restored and the Tab character will appear to the right of the word Class.

Maybe I am missing some additional IDE setting which can disable this madness, but even so this is a seriously f*cked up default behavior and it cannot but remind me of Charles Petzold saying back in 2005 how Ctrl+Z is his most used key in Visual Studio and Word – I am literally spending more time fighting the IDE than coding because of issues like this.

I am observing this problem in Visual Studio 2022 version 17.6.4.

Please fix.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 30 (17 by maintainers)

Most upvoted comments

To my great astonishment, what you and Cyrus are saying is making my expectation sound totally unreasonable, and the problem vastly more complex than it actually is.

I don’t think the request itself is unreasonable, but we have to evaluate it the same way we evaluate all the other issues that get filed:

  1. How many users are impacted? (Larger values increase priority)
  2. How long has the current behavior been present? (Shorter values increase priority; larger values increase risk that users are depending on the current behavior and will complain if it changes)
  3. How complex/old is the code that needs to be rewritten in order to change the behavior? (Simpler values increase priority)

For the old snippet experience, this issue hits a worst-case scenario in our prioritization logic, where all three metrics suggest against making a change. For the new snippet experience, item (3) is less problematic so we might be able to resolve #68985 in the new experience.