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 ;)
