I was looking into automatically moving flycheck diagnostics around when the containing file is edited, but this seems like a fairly nontrivial algorithm to implement. Is there an existing implementation or algorithm description of something like this that I could look at?
I feel pretty strongly that this should be handled by the editor
It can adjust ranges synchronously, and it doesn't need any langauge-specific info for that.
I wonder if non-VS clients do this?
Yeah, but I don't think any of them actually do this
VS Code also doesn't
Yeah... I think this is the case where it's better to not solve a problem at all, than to solve it in a wrong way.
By making range updating "async" we kind of loose any hope to have consistent results
Clients, on the other hand, can adjust ranges in lockstep with updating the text buffer (whcih they do anyway for, eg, syntax highlighting)
that said, synchronization concerns aside, this shouldn't be hard at the core
(plus, there should be additional handling for "sticky" span edges. For highlighting, you, eg, want to extend the span of idenifier if a user types next to it)
I remember seeing something about moving to a pull model for diagnostics. If a server switched to that it might be easier to get the right logic into the client
riiiight, there's also protocol-level concern that both edits and diagnostics are notifications (going in the opposite directions), so it's actually impossible to order them
(although document version might be enough for this particular case of shifting edits)
hm. can the editor do this for the check-based diagnostics though? just from how emacs behaves, it looks to me like we are sending the diagnostics with the wrong range if the user edits without saving (i.e. we're sending the old check diagnostics with the now-stale ranges again?)
Hm, I think that would be a different problem? Basically, we compute just the wrong diagnostics in this case (not only the ranges), and we should force client to save documents when computing diagnostics
well I mean our internal diagnostics are correct and move correctly, because they use the unsaved document
hmm, and if we publish internal diagnostics only, that would override the check diagnostics
Emacs doesn't move diagnostics at all by the way, it just hides all diagnostics as soon as you type and displays the new ones once they arrive
LSP issue for pull model: https://github.com/microsoft/language-server-protocol/issues/737. It looks like this is an issue about interactive diagnostics for vscode: https://github.com/microsoft/vscode/issues/103953
Isn't the push model much better suited for... everything? If the client has to pull it might not update when eg. an import now resolved because a different file changed
This is also a problem for semantic tokens, I think
@Jonas Schievink I still believe that the right model here is that of dart analysis server
push + subscriptions? yeah
yup, that one
And also requiring replies for changes notification, so that the client knows what state of the world the serve sees
Does the dart LSP stack use the subscription model? I've used their stuff on vscode for some flutter work and it's pretty slick.
I don't know