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

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

Looping in cdt-dev as some of these questions are specific to CDT's integration.

>> 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?

Yes, this is something we'd like to do eventually, although the details of how the responsibility is divided between CDT and the build system is not clear yet. Likely the actual generation of the compile_commands.json file will be done by the build system, and CDT's role will be to invoke the relevant build system functionality.

However, there is a large variety of C++ build systems out there, and some of them may not support generating a compile_commands.json file. Even for ones that do, it feels backwards to make this a prerequisite for shipping lsp4e-cpp without regressing the existing experience in the C++ editor.

> Could the LS be improved to support projects with no such file (by generating such file too)?

The LS would likely have to go through the build system as well. I'm not really sure what the usual practice / convention is here: does the LS usually invoke the build system driver (e.g. CMake, Maven, etc.)? Or is that usually the client's (IDE's) job?

>> * 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.

That seems potentially useful, thanks. How often is this property checked: once per file? Or once every time a file is opened (so we can also make it depend on the kind of editor it's opened in)?

> 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.

I think it's fine to have the markers be present (in e.g. the Problems view) as long as a Generic Editor is open, even if you happen to be looking at a C++ editor.

For the actual annotations in the C++ editor, we can probably filter them out in our ResourceMarkerAnnotationModel.

We can probably look into deleting markers when a Generic Editor is closed, but if they're not created in the first place if a Generic Editor is never opened, that might be good enough.

> 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.

Completely agreed. Any changes to LSP4E that I would propose in this regard would be opt-in / configurable.

Thanks,
Nate