Pressing Tab key causes unwanted code changes

[levicki]

Please consider this code:

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

I have removed all the code snippets for C#:

I have chosen to never include snippets:

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:

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.

[CyrusNajmabadi]

@levicki We'd def take a PR here to address this issue if you're interested in contributing!

[levicki]

@levicki We'd def take a PR here to address this issue if you're interested in contributing!

@CyrusNajmabadi

If you don't believe the issue is serious enough to assign a dev to fix it for next point release, then I am afraid I can't help. I have a paid full time job and this constant fighting with VS IDE is already negatively affecting my productivity. Even taking the time to report this was the time I was supposed to be spending writing the code for living, and meeting my deadlines at work.

Learning my way around the Roslyn codebase in order to be able to understand where the problem is and how to fix it is the time I unfortunately cannot spare at the moment nor in any forseeable future — the best I can do is report issues like this, help you reproduce, and eventually confirm the fix once it is available.

Furthermore, even if it weren't for the lack of time and domain-specific knowledge, the company I work for is already contributing to your team indirectly through various licencing fees (VS, E3, Azure, etc) they are paying to Microsoft on a regular basis.

Finally, open-sourcing just a part of a commercial product is a great way of privatizing profits and socializing lossesdevelopment costs where the benefit of open-sourcing is heavily biased towards the company cashing in on the commercial product, not towards open-source community — I have a great dislike for such practice which is another incentive not to contribute. If that means this issue will never be fixed, so be it.

[CyrusNajmabadi]

where the benefit of open-sourcing is heavily biased towards the company

It seems like it's a benefit to both sides. Users are no longer at the mercy of if an issue in the closed source side ever gets to being fixed. So if the issue isn't able to make it off the backlog based on the rest of the work the team is doing, teh community always has an option of working on things if the issue is important to them. It's a strictly better state of affairs than if the product was closed source, and i think the rest of the ecosystem, community, and contributors would prefer we stay open source :)

Learning my way around the Roslyn codebase in order to be able to understand where the problem is and how to fix it is the time I unfortunately cannot spare at the moment nor in any forseeable futur

Understood. If you ever change your mind, let us know and we'd be happy to work with you on this. Thanks!

[levicki]

... the community always has an option of working on things if the issue is important to them

You seem to be (intentionally?) conflating community and paying customers.

I am sure there are a lot of people using free Visual Studio Community Edition, but there are still many of us using Professional or Enterpise subscriptions.

While the former may be happy with the ability to fix things they consider important themselves, the latter are rightfully expecting that your team will fix the reported issues instead of relying on community contributions let alone suggesting they should roll up their sleeves and contribute a fix themselves.

This "option" also allows your team to work on issues important for internal consumption, and / or on implementing "pet features" both of which only a minority of external users might benefit from, while leaving the "boring backlog" to the community to sort out which can lead to issues reported by paying customers being neglected.

Just my 0.02.

[CyrusNajmabadi]

the latter are rightfully expecting that your team will fix the reported issues

We fix issues we have the bandwidth to fix, depending on importance and whatever else is necessary to do. That means (same as when we were closed source) there are large swaths of things that we will not get around to. Our velocity though is much higher now that we're open source, and we're able to both do more work, make more fixes, and incorporate more community efforts now that we're open source :)

instead of relying on community contributions let alone suggesting they should roll up their sleeves and contribute a fix themselves.

We regularly do. To the order of many thousands of fixes and changes. But not every reported issue will be able to get effort to fix it. So we often work with interested parties to find other ways to get the fixes in so that the people who care about them get the results quicker than having to wait for the item to make it off the backlog :)

while leaving the "boring backlog" to the community to sort out which can lead to issues reported by paying customers being neglected.

From above, there is more work needed from all our customers (including paying ones) than there are resources available to address them. This was true when we were closed source, but our velocity is much higher now that we are open source.

If you are ever interested, def drop us a line. We are very active in communities like discord, and lots of the team engages there to work with people from the community to solve problems people are running into, and to help expedite fixes for areas people are passionate about (often into the very next preview release). DotNetEvolution/Roslyn is a great place to start. Thanks! :)

[levicki]

@CyrusNajmabadi Just to be perfectly clear, the problems I have with Visual Studio and other Microsoft products are not caused by Microsoft developers working on them — they are caused by bone-headed decisions made by higher-ups who chase some ridiculous metrics for product "improvement".

Sorry for the offtopic, because what I am about to share is in no way related to Roslyn, this issue, or your team, but I think you guys need to see the latest crazy example of "what were they thinking?" moment I just had in order to better understand my frustration:

Whose "bright" idea was to greenlight this search behavior?!?

Showing those other results == blatant ignoring of my explicitly set search filters — I didn't ask for "other results" (especially not totally wrong ones!) just for the sake of having a full page of results.

This is not Bing web search where returning just a couple of (or not returning any) results might turn people away and make them use another search engine! This is a professional product aimed at developers who by definition should know what they are doing and be exact and concise. Why are the search filters there if they aren't respected? Doesn't the person who greenlighted this know that the most cardinal sin any application can commit is to allow and then ignore user input?

You may think I am overreacting, but frankly I find this behavior condescending, insulting, and disruptive in the same manner as the IDE "correcting" what I typed, or Google / Bing showing me results that aren't relevant at all for the keywords I entered.

Every day there's more of this "user engagement at all costs" in every product and service, and it makes me not want to use them at all, let alone contribute to their development.

The real problem is the internal corporate culture in large companies which seems to be tuned to maximize shareholder profits through customer engagement which allows this engagement plague to spread, and I don't see that changing anytime soon. If it continues unabated, developers will soon be more productive using Notepad and csc from the command line, at least until those tools also get the same treatment.

Sorry for the rant, and have a good weekend.

[CyrusNajmabadi]

Whose "bright" idea was to greenlight this search behavior?!?

This simply sounds like a bug. Please file feedback from within VS and this can be routed and fixed.

You may think I am overreacting,

Bugs happen. Just file issues and we can take care of things. I've never once seen a process here that engages in any of the things you're speculating about to produce result like this. What really just happens is that VS itself is a massively complex beast of a platform, with code going back 30+ years, which is constantly evolving based almost entirely on customer requests. And with that amount of code, and all the combinations of components interacting, tiny issues like this can occur.

[levicki]

This simply sounds like a bug. Please file feedback from within VS and this can be routed and fixed.

I love your optimism, but having a separate section titled "other results based on your search" doesn't seem like a bug to me — someone had to consciously design that UI element into the product.

[CyrusNajmabadi]

doesn't seem like a bug to me —

It seems like a bug to me. And if be happy to track and engage with the team on this if you're willing to file the bug.

[sharwell]

@levicki I'm not sure why the snippet matching behavior is case-insensitive, but I wouldn't be surprised if the behavior is more than a decade old at this point. A viable workaround should be to press Space, Tab if the identifier to the left of the caret happens to be a snippet trigger.

If the new behavior only recently appeared, it probably means the new snippet experience (see the following image) is failing to account for manual removal of snippets using the Code Snippet Manager. Unchecking this feature to return to the old snippet manager would restore the behavior of earlier versions of Visual Studio.