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

[Mickael Istria <mistria@xxxxxxxxxx>]

On Tue, Jun 26, 2018 at 3:56 PM, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:

 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.

The alternative to problem markers are specific text annotations, which require to basically mimic what most *DT is doing AFAIK as there is no concept of "non-marker markers" so well built-in the Platform.

So reaching the same level of integration as what marker do involve some duplication of effort.

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.

Anyway, time will tell about whether build remains an explicit step of the activity of a software developer or whether it's going to be backboxed under LSP and DAP. That's not really relevant to our discussion.

But what makes you feel like the markers provided by build are more interesting than the one provided by LS? What extra-value do they have that justifies a deeper level of integration?

I really don't think there is an objective reason to say that some should be markers and some other not and hardcode such decision in LSP4E.

I want to write a language server that does not create persistent markers. In my specific case, my build is taking care of that.

Let me go deeper in this question.

Persistent markers are not a end-user concept. They're an implementation detail and users typically don't see much what's the diff between a persisted maker and a volatile annotation at usage. So when you say you want the LS to not create persistent marker, what idea/concept are you trying to bring end-users to understand with that, what workflows do you want to enable/disable compared to markers?

 

Diagnostics from the LS would create duplicate markers.

FWIW, I do not think those duplicate markers are an issue of LSP4E but really a part of duplication of concern between what a LS does and what a build does. There is no clear rule about which one has which responsibility.

You say build markers are more important than edition markers; but actually, it could be the other way round and we could imagine that only edition should create markers (and quickfixes) and build should only be responsible of creating a package and maybe of adding some build-specific reports. For aCute and Corrosion and others, we do prefer markers because we do not have a build; we have just an export and that seems pretty satisfactory.

None is objectively better than the other in all cases.

As a workaround, until we have more options in LSP4E about how to render diagnostics; maybe your integration of LS + Build could contribute a mechanism to de-duplicate markers.

I'd like to repeat that despite my skepticism in the actual value developed by changing the current behavior; LSP4E is an open project and would welcome changes that better enable extenders to configure how markers are rendered in the IDE. But to be clear, I don't think it's something anyone from our Red Hat team is likely to do because our current feeling with LSP4E is that it's working very well as it, and that the UX is better than the one proposed by JDT volatile annotation that don't show up in Problems nor Project Explorer, and we estimate that moving to annotation a-la JDT would be a not-profitable-enough development.

Cheers,