C# snippet expansion differs in Razor than C# files

[timheuer]

Describe the bug:
When using C# snippets like prop the experience using tab differs in razor code blocks than when just in a C# file.

Version used:
VS 2022 17.0.2

To reproduce:
Steps to reproduce the behavior:

1. In a razor file trigger prop and tab tab tab
   

2. In a C# file trigger prop and tab tab tab
   

Expected behavior:
Tab expansion behaves consistently for a C# developer

Actual behavior:
Differs in razor files

Additional context:
Add any other context about the problem here.

[dibarbet]

Design review outcome:

We prefer the consistency of the snippets experience for Razor with VSCode and will be keeping Razor as-is. With the upcoming snippets work we will experiment with changing the C# experience as well.

[timheuer]

Do we think we need some customer input? This design is proposing changing the C# behavior of how a tool has behaved for a long time, where most of the users are, and how will it be different to other snippets in VS as well?

[dibarbet]

cc @akhera99 and @jmarolf who are handling semantic snippets which any experimentation here would be part of

[jmarolf]

One of the things that was discussed in the design meeting is that this behavior matches how snippets work in VS Code, and whatever we decide we would like the behavior to be as consistent as possible across editors.

Telemetry tells us that snippets are rarely used, in general, except for developers who use razor. That cohort uses snippets orders of magnitude more than any other group of .NET developer, so I think it's important to keep them happy :). As part of the work on dotnet/roslyn#56541 we should make sure that we validate people prefer or at worst are indifferent to the behavior change. @timheuer if you have any time I would appreciate your feedback and a review of our current spec (https://github.com/dotnet/roslyn/blob/b1b703abb795e4ab06bc812d0d1bd344a7c63e46/docs/ide/specs/semantic_snippets.md) for any issues. Feel free to schedule a short sync at
http://aka.ms/jmarolf if that would be easier.

[timheuer]

My higher order bit indeed is consistency. I'm not sure why VSCode won out over 20 years of existing behavior, but I'm also not saying the change is wrong -- just want consistency. I also think 'snippets are rarely used' could be a red herring. My hunch tells me that our developers see things like try prop etc. as 'IntelliSense' and less actually as we know them as a snippet feature. So it definitely would be good to have that understanding. Data-driven is good. Consistency in the C# experience is what I'm after. @KathleenDollard @MadsTorgersen should review as well. Will look at the current spec

[jmarolf]

I'm not sure why VSCode won out over 20 years of existing behavior

Personally, I think it's looking like we add an option for this but if no one is bothered and we can avoid pushing more complexity/configuration on folks. I would prefer short-term pain if we get long-term consistency across the .NET ecosystem. VS Code is very opinionated about how snippets are exposed and handled. If we wanted to standardize on Visual Studio behavior we would need to write and maintain our own snippet engine separate from the apis that VS Code provides to get that experience in that editor. But my understanding of the thinking here is that the majority of web developers and new folks coming in would be familiar with the VS Code behavior as it is the predominant editor for web development.

My hunch tells me that our developers see things like try prop etc. as 'IntelliSense' and less actually as we know them as a snippet feature.

We can attempt to interview/survey developers but as you say I do not think most folks are not consciously aware of what features they use. I am just looking at the telemetry data for VS. Only a fraction of a percent of developers who do not user razor ever register as committing a snippet. That doesn't mean we can do whatever we want though. For features like these that haven't changed since they shipped in 1.0 any change will be disruptive. Folks that have existing workflows should not be broken. In this case we couldn't produce a workflow that was broken by this change and so we thought it better to make it and respond to feedback.

[timheuer]

Balancing act for sure...new developers/new behavior or existing (larger base) developers and move their cheese :-). We're on the same page for consistency FWIW, that's my goal. I'm personally indifferent to the change and think my muscle memory can adapt...but I'm n=1 LOL