Only have valid Html content in Virtual Html document

[NTaylorMullen]

Right now if you have the following in your Razor file:

@{
    if (1 < 2)
    {
        ...
    }
}

<str

And you try invoking completion on the <str you get no completion. This is something that could definitely be fixed on the Html language service side but should also be addressed by us. This is the first issue I noticed by duplicating the Razor content in the Html buffer but it'd be wise of us to replace all C# content in the HTML buffer with spaces to avoid any further issues.

[SteveSandersonMS]

Two ways we could approach this:

• We could change the "language request" notion from a pull model to a push model. That is, every time the host document changes, the .NET server could send an updated list of classified spans to the client. Then:
  • When the client wants to do a language lookup request, it can resolve it locally - no more language queries to the server every time the mouse or cursor moves.
  • When the client wants to provide the contents of the projected HTML document, it can use its local knowledge of classified spans to replace all the C# spans with whitespace. This could still be expensive in a very large document (since we don't have diffs - we just know that the host document changed in an unspecified way) but not necessarily more expensive than getting the .NET side to blank out the C#.
• Or, every time the client wants to provide the contents of the projected HTML document, it could make a request to the .NET server which returns a version of the host document and uses its knowledge of classified spans to blank out the C# spans.
  • This feels a bit expensive because we'd be processing the entire document from scratch on both sides of the channel on every keystroke. I'm not sure if we have enough knowledge of the diffs on the .NET side to only update the affected parts of the blanked-out projected HTML document.

Got any opinions on this?

[NTaylorMullen]

We could change the "language request" notion from a pull model to a push model. That is, every time the host document changes, the .NET server could send an updated list of classified spans to the client. Then:

We'd still need to have a semi-pull model in cases when the server hasn't finished parsing the document and therefore hasn't pushed down classified spans yet. That's what this issue covers. As of right now if you're typing C# completions there are times when the server will fall behind slightly and you'll get mismatched completions; same would occur for Html.

Or, every time the client wants to provide the contents of the projected HTML document, it could make a request to the .NET server which returns a version of the host document and uses its knowledge of classified spans to blank out the C# spans.

I think we can mix this and the previous one to come up with a good solution. In the end it'd function a lot like the synchronization of the C# buffer today. Basically, as a user types we'll be calculating HTML documents and refreshing them on the client as results become ready; however, once a user-action occurs we'll ensure our documents are synchronized (but with blanked out spaces) and then perform that user-action.

[NTaylorMullen]

Hmm, since attributes shouldn't matter in regards to < > etc. we could even re-run the coloring TextMate grammar (or something functionally similar) to strip out all potential C# bits 🤔

Curious how well that would work; would be damn fast too.

[SteveSandersonMS]

@NTaylorMullen The TextMate grammar idea is a very good one, though on investigation it might be rather CPU-intensive.

VS Code itself doesn't appear to expose any API to observe the built-in textmate tokenization, or even the generated colors. There is a command vscode.executeDocumentColorProvider but when I try it, it always returns an empty array. Even if it succeeded it wouldn't really help because it returns actual RGB color values, whereas what we want are the TextMate scope names so we know which text ranges should be considered "in C#" or not.

So if we do want to evaluate the TextMate scopes, the recommended approach appears to be using the vscode-textmate package, which is what VS Code itself uses. However their benchmarks show it can take 500ms or more on ~1MB files. VS Code does some more complex stuff to track the result and update it incrementally on edits. We could replicate all that but it's adding a lot of sophistication, and even so won't be as precise as asking the Razor language service for the classified spans.

[NTaylorMullen]

Ahh, awesome investigation. Ya that seems like an issue. I thought they'd have better perf results than that given the regex is responsible for all of the coloring.