[#98] Add SymbolTag values for access modifiers and other modifiers

[travkin79]

I suggest to add more SymbolTag values to the LSP specification as implemented in this PR. This PR should solve issue #98.

[travkin79]

@microsoft-github-policy-service agree company="Solunar GmbH"

[dbaeumer]

@travkin79 thanks for the PR. To get something into the specification we need an implementation in one of the clients / servers as well. This can be VS Code or another editor. See https://github.com/microsoft/language-server-protocol/blob/main/contributing.md

[dbaeumer]

Are you planning on working on such an implementation?

[travkin79]

Hi @dbaeumer,

To get something into the specification we need an implementation in one of the clients / servers as well.

Thank you for the hint. I didn't know that, but I'll check the contribution guidelines.

Are you planning on working on such an implementation?

I didn't plan to extend the VSCode client or server libs (yet), since I'm not familiar with TypeScript or VSCode, but I can check if I could do it. Nevertheless, my goal is using the new symbol tags in CDT LSP (C++ plug-ins for the Eclipse IDE). But this will require adapting clangd (which I'm also not familiar with) and in best case should include adapting the LSP specification. My motivation comes from this discussion.

I prepared this PR, because I hoped for more progress on this topic. I thought, making the proposals mentioned in the issue more concrete (e.g. with the PR) simplifies discussing the details. We could convert this PR to a draft if you like.

Besides, since I only added new values to an existing type (SymbolTag), do we need a language server (and client) to actually use each of the new values? I guess, the already existing SymbolTag value Deprecated is already being used in a reference implementation, doesn't it?

I suggest the following steps to proceed:

1. Discuss and decide about my proposals contents, i.e. the new SymbolTag values.
2. Check if we can / have to extend one of the clients / servers to use the new values.

[dbaeumer]

If we only add the values to the spec, but now client is using them then it is misleading for server implementors. This is why even for enum values, tags, ... we want to make sure we have an implementation.

[jens-elmenthaler]

Const for C++ would be useful, too

[travkin79]

I reconsidered a Const tag and I think we can use the ReadOnly tag for that purpose. Having both tags, Const and ReadOnly might be confusing since they mean the same in principle. Besides, I don't think, we should use many language-specific keywords as tags in LSP specification. Instead, we should describe the concepts behind them.

[travkin79]

If we only add the values to the spec, but now client is using them then it is misleading for server implementors. This is why even for enum values, tags, ... we want to make sure we have an implementation.

Hi @dbaeumer,
Would it be sufficient if we had a server implementation in clangd (for C++) and a client implementation in LSP4E and / or CDT LSP, instead of extending the VSCode libs?

[dbaeumer]

Yes, an implementation in another client is sufficient as well.

[nixel2007]

Hi there. Could you elaborate on the idea behind adding access modifiers as symbol tags? There is another request for semantic highlighting where client can get additional semantic information for rendering purposes. Why is this needed on symbol level on client side?

[travkin79]

Hi @nixel2007,

Hi there. Could you elaborate on the idea behind adding access modifiers as symbol tags? There is another request for semantic highlighting where client can get additional semantic information for rendering purposes. Why is this needed on symbol level on client side?

I think, it might be better to discuss the rationale in the corresponding issue #98. But for the sake of simplicity, here's my answer:

My goal is to display symbol details like access modifiers / visibility (public, protected, private, etc.) and flags like static, abstract, final, etc. in LSP clients, usually in various editors and their views, for example in the Eclipse IDE outline view or in VSCode's side bar (explorer / project tree) as well as other views like a call hierarchy or type hierarchy. Originally, I've discussed that in eclipse-lsp4e/lsp4e#977, where I also compare the Eclipse IDE outline view contents for Java, C/C++ (non-LSP editor), and the LSP-based C/C++ editor's outline view, which is missing many details because of LSP's limitations.

After reading the LSP specification, I think, document symbols are appropriate to carry such details in symbol tags, since they are used in the document symbol request (often used for the outline view, e.g. in LSP4E, i.e. in Eclipse IDE) and also in call hierarchies and type hierarchies. In contrast, semantic tokens are usually used for coloring the text in an editor, not for outline views and other hierarchical views.

Besides, some language servers like clangd (for C/C++) do respond with very few details about the tokens, usually only lexical tokens (e.g. comments, keywords, number literals, char literals, string literals,...) without details about an element's (a symbol's) visibility or other details. The reasons for that are: (a) Some of these details require a more accurate analysis, e.g. deciding if a method overrides another method or implements an interface or an abstract method from a parent class (in Java). It's not sufficient to analyze a single file visible in an editor. (b) Tools like CDT LSP, the C/C++ editor and LSP client, and also VSCode do use TextMate grammars for syntax highlighting (see TM4E) and do not use / need these details from the language server (here clangd). Check clangd/clangd#1115 (comment) for a related discussion.

[nixel2007]

This is clear, thank you for explanation!