[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [lsp4e-dev] LSP4E diagnostics outside of generic editor
|
Thanks. Not tying LSP4E to the Generic Editor makes sense.
That said: if, in our first iteration of CDT/LSP integration, we would like LSP-related features to only be present in the Generic Editor, and not in our C++ Editor, is there a way to set that up?
Thanks,
Nate
________________________________________
From: lsp4e-dev-bounces@xxxxxxxxxxx <lsp4e-dev-bounces@xxxxxxxxxxx> on behalf of Mickael Istria <mistria@xxxxxxxxxx>
Sent: June 24, 2018 7:38:38 AM
To: lsp4e developer discussions
Subject: Re: [lsp4e-dev] LSP4E diagnostics outside of generic editor
Hi,
Yes, this is expected as diagnostics are rendered as resource markers (that allows to have them showing the warning/error decoration of resources in project explorer and also to see them in the progress view.
It's also intended to make it easy to bind some LS analysis to any file independently of the editor. Red Hat Developer Studio uses that to get a LS running in regular pom.xml editor and show addition as warnings.
In general, LSP4E tries to minimize its adherence to generic editor. The generic editir is the editor that's supported by default because it's the one that seems the most profitable, but we could entirely imagine plugins that reuse LSP4E code as it to extend the SSE, Java or CDT editors. We must avoid the code to depend too much on the editor type in order to keep other integrations affordable.
Hth
--
Mickael Istria
Eclipse IDE<https://www.eclipse.org/downloads/eclipse-packages/> developer, for Red Hat Developers<https://developers.redhat.com/>
