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

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey Gunnar,

it sounds to me like the language server is responsible for deciding which strategy to use here. Some might choose the first, others the second approach.

And as far as I know, language servers can react to file close events and clean up diagnostics already, which is independent of the editor that was used to open the file.
Why do we need something special on the client side for LSP4E here while VS Code seems to keep all this logic completely on the language server side?

Cheers,
-Martin





> 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
> 
> -- 
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx, http://guw.io/
> 
> 
> 
> 
> 
> 
>> On Jun 26, 2018, at 08:36, Mickael Istria <mistria@xxxxxxxxxx> wrote:
>> 
>> 
>> 
>> 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@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/lsp4e-dev
> 
> _______________________________________________
> lsp4e-dev mailing list
> lsp4e-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/lsp4e-dev