Another possible bug? Doing a move lines (Alt+Up) in VS triggers a textDocument/didChange notification and an /edits request, but it looks like it comes back empty, so the transplanted line isn't colorized.
Talked with @gundermanc. What was happening here was we were returning 0 edits, which is correct according to the spec as far as I can tell, but doesn't jive well with the way the VS tagger works. This issue now tracks confirming this scenario once we believe things are in a good state, rather than specifically making a change on our side.
External issue tracking this: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1159270
The external fix is currently targeting Preview2
Looks like still an issue in latest VSMain 30431.40.main:

/cc @gundermanc
Looks like still an issue in latest VSMain 30431.40.main
Updating.. is this in Local, LiveShare, or CodeSpaces?
Ok, I have repro, looks like this is another narrow _mapping diff changes_ corner case. I'll aim to take care of this for Preview 3 or Preview 4.
Note that the core case is fixed, this only repros if you have exactly 2 lines and move the top line down, I think.
Note that the core case is fixed, this only repros if you have exactly 2 lines and move the top line down, I think.
I actually had a bit more then what was shown in that gif:
@page "/"
<h1>Hello, world!</h1>
Welcome to your new app.
<SurveyPrompt Title="CAPS" />
<SurveyPrompt Title="NOT!" />
<input @onclick="@(() => Foo(x))" />
@code {
partial void Foo(string bar)
{
}
}
Ok, this was another weird edge case around editor span tracking and the difference between Overlaps and Intersects. This seems to have fixed it: https://devdiv.visualstudio.com/DevDiv/_git/VSLanguageServerClient/pullrequest/273235
Confirmed resolved. Thanks @gundermanc!
I'm still seeing a "flash" when I ALT+UP, is that expected?

Note; the gif doesn't capture it, but the flash occurs every time I ALT+UP (gif shows it stopping after a bit)
is that expected?
From the editor's perspective, alt+up/alt+dn aren't moving lines, they are deleting one line and inserting a new one. At the time the edit is made, the new line doesn't have any semantic tokens colorization information because the inserted line pushed all the existing tags down a line.
What you are seeing is:
I guess in this case we could move the tag position restoration behavior from being async, and part of the LSP request code path, to being done synchronously on the UI thread when an edit doesn't change the text diff, though that's a pretty expensive optimization.
What is the behavior in VS Code in this scenario?
Thanks for the explanation, much appreciated!
though that's a pretty expensive optimization.
Yeah, I don't think this is a big enough issue to warrant that, it would probably make the overall experience "feel slower".
What is the behavior in VS Code in this scenario?
Same sort of 'flashing'.