Annoying Intellisense/autocomplete in Razor files using Visual Studio Insiders

[DaveNatalieTripArc]

I recently installed the Visual Studio Insiders edition, and my intellisense/autocomplete is completely messed up compared to previous versions.

Any time I try to write @if it auto completes to @IFormatProvider, and any time I try to write null, it changes to nuint.

I have made a video demonstrating the problem in a completely fresh project.

https://youtu.be/4nX1mivR0s4

I am using Visual Studio Insiders 11206.111 with .Net 10.0.100

[davidwengier]

Thanks for the awesome video! Looks like you're hitting two different issues.

Our @if directive snippet isn't showing up in intellisense.

This is our bug and we'll take a look. It might be affecting over directives or snippets, but interestingly @code was present so not sure. Unfortunately this doesn't repro for me, at least from a quick test with an old project of mine. I'll try to mimic your repro directly.

Roslyn is sorting nunit before null

Based on the discussion in dotnet/roslyn#68841 it seems like this is only a "first time" problem, and should go away once you type nu, down arrow, then accept null. Perhaps because Insiders is a new install, that MRU info is reset? Though I must say, I can repro this issue and even after selecting null a few time it's still not being preselected for me.

@CyrusNajmabadi/@dibarbet do you know if the MRU for completion items works in LSP?

[dibarbet]

@CyrusNajmabadi /@dibarbet do you know if the MRU for completion items works in LSP?

It looks like the MRU implementation is in the part of completion that integrates directly with the VS Editor, so I would expect that it does not work in LSP. Especially since generally LSP doesn't participate in filtering (though we work around that to some extent).

[davidwengier]

Would dotnet/roslyn#44451 apply to LSP? Or do we need a different targeted fix there?

[dibarbet]

Would dotnet/roslyn#44451 apply to LSP? Or do we need a different targeted fix there?

Solid maybe... the match result I believe is calculated during filtering, and in LSP the server isn't called to handle filtering, unless you mark the list as incomplete.

We do kind of sort by that result upfront, but not sure if the client respects that.

I see a couple options

1. always mark the list as incomplete so the server gets called back on every keystroke. would allow the server to force a specific sort and filtering, but has the drawback of being way more chatty (serializing more completion lists).
2. might be able to force a certain initial ordering by specifying the sorttext based on the match result upfront. we do that in vscode but I am not sure how VS will handle the sort text on further typing - https://github.com/dotnet/roslyn/blob/main/src/LanguageServer/Protocol/Handler/Completion/CompletionResultFactory.cs#L146

[davidwengier]

Number 2 is what I was thinking of, for sure. I'm fairly sure we use sort text in VS without issue, though probably with nothing quite so closely matching that you'd notice after the first character.

[davidwengier]

Random shower thought for number 1: I wonder if this is Roslyn semantic snippets?

When Roslyn introduced semantic snippets, it broke Razor because it wouldn't offer the if snippet outside of a code block. This is because until you actually write code after an @ in Razor, the compiler doesn't know if it should go in the class, or the render method. Roslyn is "smart" enough not to show if as a completion option if you're at the class level, and of course as soon as you do type @if the Razor compiler is smart enough to put that in the render method, and everyone is happy. Except the user who was just trying to type :)

So as a consequence, we turned off semantic snippets for Razor files, as a temporary workaround. 3 years later is still temporary, right? Anyway, that "turn off for Razor files" is probably broken for cohosting, so we're back in this position. So the plan, in #6927, is for us to add back our own snippets for @if (and maybe @for, @foreach etc.) to this list and then I think we might be good.