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

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

> In term of organization of your development, especially for a 1st iteration, then I think it's also questionable whether you want to spend effort in disabling features that can turn being profitable on the long run. If I were to see a demo of the LSP-based C++ tools in Eclipse IDE and would see markers from the LS inside the C++ editor, I would personally find it positive and acceptable for a 1st iteration. Additional markers don't have a negative impact usually, and showing them can drive to some more thoughts.

If the user has configured their LSP integration correctly, and then opens a file in the C++ editor and sees the LSP4E diagnostics there, sure, that's great.

But what I'm finding is that the mere presence of the lsp4e-cpp plugin is sufficient to launch the language server and show LSP4E diagnostics, even if the user has only ever used the C++ editor.

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.

Obviously, we cannot ship lsp4e-cpp (even a first iteration) in this state.

It seems like what we would want is:

 * 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

Is this possible to achieve? Perhaps with some appropriate changes/enhancements to LSP4E?

Thanks,
Nate