Consider using LSP Diagnostic Pull?

[karlhorky]

trafficstars

Hi @usernamehw ! 👋 Hope you are well.

As a follow-up to #55 and #57, do you think that the new LSP Diagnostic Pull proposal (from this original issue) would be a good fit for Error Lens, once it's available? This would make getting the diagnostics more efficient, and allow for a pull-based mode to better implement onSave.

There was an announcement in the release notes for VS Code 1.54: https://code.visualstudio.com/updates/v1_54#_language-server-protocol

Language Server Protocol

A first proposal of a diagnostic pull model got implemented for the upcoming 3.17 release. The proposal is available in the next versions of the VS Code LSP libraries.

[usernamehw]

Alright, subscribed to closing event of https://github.com/microsoft/language-server-protocol/issues/737 . It's not finalized yet, yes?

[karlhorky]

Yeah I think it's been implemented by @dbaeumer, but only as a proposal: https://github.com/microsoft/vscode/issues/117042

I guess it's going to come in the 3.17 LSP release? Not sure what that means regarding which VS Code version it will land in though...

[karlhorky]

Ah, there's a draft version of the diagnostic pull model specification now open for feedback:

https://github.com/microsoft/vscode-languageserver-node/blob/main/protocol/src/common/proposed.diagnostics.md

[karlhorky]

I guess this "got published", apparently? https://github.com/microsoft/vscode/issues/112501#issuecomment-872809765

I asked over here about documentation on how to use it: https://github.com/microsoft/language-server-protocol/issues/737#issuecomment-898260753

[karlhorky]

Alright, pull-based diagnostics were shipped in v3.17 of the language server protocol! 🙌

Would be so great to have this trickle down to extensions to make them more performant 👍

[usernamehw]

I ... don't remember what this issue is about. No action is planned. Going to close it.

[karlhorky]

I think it would make Error Lens more efficient:

This would make getting the diagnostics more efficient, and allow for a pull-based mode to better implement onSave.

Currently saving the file to update the Error Lens is a bit of a cumbersome UX. (sometimes requires multiple saves of a file to get rid of invalid / outdated Error Lens decorations)

But I also had a hard time tracking the various PRs and issues where this was being implemented.

Wonder if @dbaeumer could add some feedback here as to whether my research is correct that this VS Code feature / API could be used to improve the UX of Error Lens to make it not require saving as much...?

[usernamehw]

I've changed a little bit how "onSave" works. Maybe it's fine as it is in 3.20.0?

[karlhorky]

Thanks for the updates ❤️ I'll keep an eye on how it behaves over the next weeks/months.

[dbaeumer]

Not sure what pull diagnostics should bring here since the extension is not running a language server to my knowledge.

[karlhorky]

Ok, sorry for the noise! I must have misinterpreted the feature (and what extensions it could be used for) somewhere along the way.

[karlhorky]

I've changed a little bit how "onSave" works. Maybe it's fine as it is in 3.20.0?

Thanks for the updates ❤️ I'll keep an eye on how it behaves over the next weeks/months.

So I saw one "stale" Error Lens decoration today, and this is something that happens more commonly:

1. An ESLint error (from SafeQL) appeared in one file
2. A change (database migration) caused the squiggly error underline to disappear (could also be edits in another file or some other change)
3. The Error Lens decoration remained

Error Lens seems to be 1 change behind the squiggly in these circumstances.

Video:

https://github.com/usernamehw/vscode-error-lens/assets/1935696/75bc801c-feef-4b52-a62c-56144e45958a