Re: [lsp4e-dev] LSP4E diagnostics outside of generic editor

[Mickael Istria <mistria@xxxxxxxxxx>]

Hi Gunnar,

Is there some design document which described the motivations behind such critical key decisions?

The motivation is to show the error marker in the Project Navigator and the Problems view and any editor, where user like to see them and wherever they can provide value.

Markers are very well integrated in many places of the IDE, I'd rather have LSP4E use highly integrated concepts than reinventing the wheel and duplicating integrations.

The use of persistent resource markers does not seem right to me. This is for the very simply reason that a language server is not a compiler/builder. 

I don't think markers are reserved to compiler/builder.

Moreover, we're moving to a world where the compile/build step becomes unnecessary and are a black box of LSP or Run/Debug. So with the reasoning of having markers only for builder, it means that progressively, we'll stop using markers at all while they are very well integrated.

FWIW, I checked the spec and it seems that there is some guidance on the topic: 

----

Diagnostics are “owned” by the server so it is the server’s responsibility to clear them if necessary. The following rule is used for VS Code servers that generate diagnostics:

- if a language is single file only (for example HTML) then diagnostics are cleared by the server when the file is closed.

- if a language has a project system (for example C#) diagnostics are not cleared when a file closes. When a project is opened all diagnostics for all files are recomputed (or read from a cache).

----

 

Thanks,  I didn't see those hints.

So it seems the persistent marker for everything rule in LSP4E is targeted for the second style of projects.

Yes.

 

Would it make sense to allow a language server to express how diagnostics should be persisted (eg., only temporary in editor or always persistent)?

First, let's wonder, what's the issue you're trying to fix here? I'm afraid we're going to debate dogmatic decisions without a user-story to support the discussion and drive us to pragmatic decisions, and that will lead us nowhere interesting ;)

I would appreciate if you can open bug reports containing a user-story to drive the discussion on this topic. There is already https://bugs.eclipse.org/bugs/show_bug.cgi?id=518508 on this topic, but still it's missing a clear user-story (other than "JDT does this") to support that one approach is better than the other.

Your suggest wouldn't fix initial issue reported by Nathan and is not really related. How diagnostics are stored internally doesn't correlate with which editor they target. So if it's a marker or an annotation, if it's persisted or not, doesn't change the fact of deciding when to show them or not.

Adding options to LSP4E is always a good thing, but it requires some development and have some maintenance cost; if you're ready to pay that price to overcome some issue that would for sure be welcome.