Add configuration option for disabling semantic highlighting

[DavidHancu]

As the title says, Rust Analyzer should provide a configuration option that allows users to completely disable semantic highlighting. Some extensions may want to override Rust Analyzer's semantic highlighting, but they can't since Rust Analyzer takes precedence.

[Veykril]

Is this in the context of VSCode? I wonder if you can force VSCode to load/activate extensions in a specific order?

[DavidHancu]

Yes. I don't believe that you can configure extension priorities.

[DrGo]

wondering if there is a way to disable semantic highlighting..

[davidbarsky]

there isn't a configuration option right now, but there can be.

[Veykril]

Imo this should be something offered by VSCode, disabling it per extension/language, it already has support for limiting configs to that. I don't see why rust-analyzer has to make up for it, the client is already in full control of enabling/disabling this.

[DavidHancu]

Imo this should be something offered by VSCode, disabling it per extension/language, it already has support for limiting configs to that. I don't see why rust-analyzer has to make up for it, the client is already in full control of enabling/disabling this.

Disabling it per language is not enough, I want semantic highlighting for rust to be provided by another extension other than rust analyzer

[DrGo]

there isn't a configuration option right now, but there can be.

I think that will be highly appreciated. Do you need a PR?

[Veykril]

Well I stand with that this ought to be a VSCode feature itself, though knowing them that isn't gonna happen anyways so I guess we gotta bite. If we are going to have this as a config this should be a VSCode extension only config though (not a config on the rust-analyzer server itself). The config itself should toggle the corresponding capability here to disable it I think? https://github.com/rust-lang/rust-analyzer/blob/67f7eb505e3aaf37db4bc805c79c95f9be44e2a5/editors/code/src/client.ts#L366-L373

[DrGo]

what is the downside of allowing users of other editors to disable this feature?

[Veykril]

An editor has the option to disable this feature at the LSP level, it makes little sense for the server to have a configuration that changes its own server capability. Especially because that means it would require a restart from the client when changing said capability. In other words, a server configuration is redundant here as the capability system of the LSP already acts a configuration system for LSP features. Additionally, the config does nothing for some clients that don't even support semantic highlighting.

As such, I see this as the responsibility of the client, not the server.

[DrGo]

An editor has the option to disable this feature at the LSP level, it makes little sense for the server to have a configuration that changes its own server capability. Especially because that means it would require a restart from the client when changing said capability. In other words, a server configuration is redundant here as the capability system of the LSP already acts a configuration system for LSP features. Additionally, the config does nothing for some clients that don't even support semantic highlighting.

As such, I see this as the responsibility of the client, not the server.

I am not familiar with the LSP protocol. How can I disable semantic highlighting in neovim?

[Veykril]

I don't know, I don't use neovim. I'd expect the corresponding documentation to describe that