| Mickael,
Is there some design document which described the motivations behind such critical key decisions?
FWIW, I find the current implementation of LSP4E with that regard also troubling. 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.
What I've observed in VS Code is that the LS provides diagnostics while editing a file. However, problems in the problem view are generated by different processes running as part of a build (eg., lint). The Java Editor behaves similar as well. It uses a CompilationUnitAnnotationModel to show temporary problems while editing a file in addition to resource markers. Only the JDT compiler generates persistent markers when a file is saved and processed as part of a build.
Thus, I'm wondering about the motivation for these decisions.
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). ----
So it seems the persistent marker for everything rule in LSP4E is targeted for the second style of projects. Would it make sense to allow a language server to express how diagnostics should be persisted (eg., only temporary in editor or always persistent)?
-Gunnar
On Tuesday, June 26, 2018, Nathan Ridge < zeratul976@xxxxxxxxxxx> wrote:
So all it takes is for a user not to have a compile_commands.json file in their project directory (which most projects today don't) and the language server will litter the file with "include not resolved", "name not resolved" etc. errors because it doesn't know the project's configuration.
Have you considered generating a compile_commands.json file before starting the LS if no such file exists? Could the LS be improved to support projects with no such file (by generating such file too)? I think additionally to removing this issue from LSP4E bucket, it could enable the best UX for many cases.
* The language server is only running as long as at least one Generic Editor is open
* LSP4E only sends the server requests related to those files which are open in a Generic Editor
The LS/Content-Type extension point allows an enabledWhen which may be able to address that. You can for example create a property that checks whether the currently active editor is the Generic Editor and have in the enabledWhen a check of the property. But in any case, if you have the Generic Editor open on one file, it will show diagnostics on all editors with the same file, including the C++ one. So a workaround is to have some listener removing the markers when you don't want them.
Is this possible to achieve? Perhaps with some appropriate changes/enhancements to LSP4E?
If we can deal with it by enabling some better enabledWhen or other configurable conditions in LSP4E, it'd be entirely welcome. But I really would like to avoid LSP4E to assume it's only working on Generic Editor. There are already cases of other editors (Spring properties, pom.xml + Fabric8, xml + Apache Camel) that do rely on LSP4E in other editors than Generic Editor. We must not break them at all nor require them any specific action to keep working. Concrete ideas of things to change to better allow this are welcome as enhancement request and Gerrit patches ;)
_______________________________________________ lsp4e-dev mailing list lsp4e-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/lsp4e-dev
|
