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