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

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Mickael,

Comments below.

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.

I'm not questioning the concept of markers. I'm aware that they are widespread and very integrated throughout the IDE. I'm also not talking about reinventing the wheel and duplicating integrations. I'm really confused that you imply all that based on my question for motivation. Sight.

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.

That's actually not what I wrote.

Moreover, we're moving to a world where the compile/build step becomes unnecessary and are a black box of LSP or Run/Debug.

No, I disagree. It might be something that you are interested in. But I''m lacking context of who "we" is and why the world is moving away from build. Even VS Code has a very good integration of build systems and exposes this explicitly as part of the build.

 

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 want to write a language server that does not create persistent markers. In my specific case, my build is taking care of that. Diagnostics from the LS would create duplicate markers.

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/