You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reacted by Marc-Andre Laperle, Nathan Ridge, Adrian Vogelsgesang, Lars Hvam, 康小广, Jeremy Kolb, Marcin Krzyzanowski, Alex Kladov, Marco Groppo, Łukasz Samson and 13 more
Some languages make a fundamental distinction between a function that has a return type and a "function" that doesn't return anything, unlike in C for example where it's simply determined by whether or not the return type is void, so it would be useful to have a separate symbol kind that could be called for example Procedure.
Reacted by Lars Hvam, Maik Riechert, Pedro Ricardo C Souza, Samuel Kelemen, rubenporras and gerdleon
This list (attribute/annotation, union, typeAlias) is what's been implemented in rust-analyzer for a while, and which feels general-purpose enough to uplift to the protocol proper.
Oh, my bad, I confused both SemanticTokenType with SymbolKind, and server with client, sorry about that 🤦
But yeah, rust-analyzer will be ready to use macro, typeAlias and union for SymbolKind as soon as they are available! I don't think we can do this before the protocol is stabilized though: SymbolKinds, unlike SemanticTokenTypes, are not extensible.
Otherwise only having them in the spec with no implementation is not very helpful
They're valuable once implemented in both server and client, so there's a first-mover disadvantage.
We have several language servers saying they're willing to go first, but are unwilling to break the spec in order to do so. So having them in the spec solves the coordination problem (and practically, avoids having servers and other clients blocked on VSCode prioritizing this).
(FWIW I'd be eager to add both server and client support for StaticField and StaticMethod or so for both client and servers - the server is open-source but the client is not)
IMO StaticField and StaticMethod shouldn't be new symbol kinds. If we want to express this we should adopt the way how this is handled in semantic tokens. So I would rather have a SymbolModifier which says static, async, ..
Since this enum can't be extended by clients/servers, it would be useful to have unknown or other or something.
For C++ we'd like to be able to include macro expansions (not definitions) in the hierarchy in certain cases. (Basically, when a macro dumps a bunch of implementation-detail symbols with into a namespace, the outline is pretty confusing if we can't group those somehow). This is a weird thing to do and I'm not sure it makes sense to add a macroExpansion kind to LSP (especially if VSCode folks don't want more kinds). On the other hand, having to pretend these symbols are nulls or namespaces or something is pretty bad!
(I do agree with your point about StaticField and StaticMethod... the semantic tokens data model is nice!)
Just to confirm, if we wanted to implement this, we'd need to include support for a client as well, likely VS Code, right? How would we go about making contributions to VS Code - what needs to be done to support it in VS Code exactly? New icons + support for the new symbol kinds?
If you want new kinds to light up in VS Code then yes, we need support for VS Code as well. We can still extend the list in LSP and guard the new symbol kinds using a capability.
Some languages make a fundamental distinction between a function that has a return type and a "function" that doesn't return anything, unlike in C for example where it's simply determined by whether or not the return type is void, so it would be useful to have a separate symbol kind that could be called for example Procedure.
Languages like C/C++ need a distinction between constructor and destructor, so adding Destructor to SymbolKind would improve the UI (see also CDT LSP issue eclipse-cdt/cdt-lsp#608).
Another option would be to use SymbolTags to annotate methods as destructors or constructors, similar to PR #2003 using symbol tags to annotate document symbols with details like public, static, final, and other flags / keywords. In this case I would deprecate SymbolKind.Constructor in favour of a new Constructor symbol tag (and of course also a Destructor symbol tag).
Activity
vladdu commentedon Nov 27, 2017
I assume it's best to propose one item per comment, so that people can vote for it.
vladdu commentedon Nov 27, 2017
vladdu commentedon Nov 27, 2017
rictic commentedon Nov 27, 2017
Slot, in the sense of a named, declared hole in a template that a user of the element can use to insert content.
e.g.
<slot>in Shadow Dom v1,<content>in Shadow Dom v0, transclusion points in AngularJS,<ng-content>in Angular.laughedelic commentedon Nov 29, 2017
Value: There isCompletionItemKind.Value, but noSymbolKind.Valuetsmaeder commentedon Dec 18, 2017
Annotation
raja-s commentedon Jan 8, 2019
Some languages make a fundamental distinction between a function that has a return type and a "function" that doesn't return anything, unlike in C for example where it's simply determined by whether or not the return type is
void, so it would be useful to have a separate symbol kind that could be called for exampleProcedure.raja-s commentedon Jan 8, 2019
Typefor type declarations.raja-s commentedon Jan 10, 2019
Parameter/Argumentto be able to distinguish function/constructor/... parameters from actual variables.kenkangxgwe commentedon Jan 25, 2019
Sectionfor typesetting languagesdbaeumer commentedon Jan 25, 2019
康小广 (@kenkangxgwe) can you provide me with an example.
kenkangxgwe commentedon Jan 25, 2019
Dirk Bäumer (@dbaeumer)
In LaTeX,
In Wolfram Language
In MATLAB
%%Introduction // ...In C#
#region section // ... #endregionKamasamaK commentedon Jan 25, 2019
Markdown also has sections. The VS Code built-in extension is currently using
SymbolKind.Stringfor them.13 remaining items
matklad commentedon Nov 17, 2020
This list (
attribute/annotation,union,typeAlias) is what's been implemented in rust-analyzer for a while, and which feels general-purpose enough to uplift to the protocol proper.dbaeumer commentedon Nov 17, 2020
Alex Kladov (@matklad) this is about
SymbolKindand not about semantic tokens.matklad commentedon Nov 17, 2020
Oh, my bad, I confused both SemanticTokenType with SymbolKind, and server with client, sorry about that 🤦
But yeah, rust-analyzer will be ready to use
macro,typeAliasandunionforSymbolKindas soon as they are available! I don't think we can do this before the protocol is stabilized though: SymbolKinds, unlike SemanticTokenTypes, are not extensible.sam-mccall commentedon Dec 8, 2020
They're valuable once implemented in both server and client, so there's a first-mover disadvantage.
We have several language servers saying they're willing to go first, but are unwilling to break the spec in order to do so. So having them in the spec solves the coordination problem (and practically, avoids having servers and other clients blocked on VSCode prioritizing this).
(FWIW I'd be eager to add both server and client support for
StaticFieldandStaticMethodor so for both client and servers - the server is open-source but the client is not)dbaeumer commentedon Dec 9, 2020
IMO
StaticFieldandStaticMethodshouldn't be new symbol kinds. If we want to express this we should adopt the way how this is handled in semantic tokens. So I would rather have a SymbolModifier which saysstatic,async, ..KamasamaK commentedon Dec 9, 2020
Dirk Bäumer (@dbaeumer)
Did you mean
SymbolTag?dbaeumer commentedon Dec 9, 2020
KamasamaK yes sorry. Was confused with semantic tokens.
sam-mccall commentedon Feb 25, 2021
Since this enum can't be extended by clients/servers, it would be useful to have
unknownorotheror something.For C++ we'd like to be able to include macro expansions (not definitions) in the hierarchy in certain cases. (Basically, when a macro dumps a bunch of implementation-detail symbols with into a namespace, the outline is pretty confusing if we can't group those somehow). This is a weird thing to do and I'm not sure it makes sense to add a macroExpansion kind to LSP (especially if VSCode folks don't want more kinds). On the other hand, having to pretend these symbols are nulls or namespaces or something is pretty bad!
(I do agree with your point about StaticField and StaticMethod... the semantic tokens data model is nice!)
DavidGoldman commentedon May 5, 2021
Just to confirm, if we wanted to implement this, we'd need to include support for a client as well, likely VS Code, right? How would we go about making contributions to VS Code - what needs to be done to support it in VS Code exactly? New icons + support for the new symbol kinds?
dbaeumer commentedon May 10, 2021
If you want new kinds to light up in VS Code then yes, we need support for VS Code as well. We can still extend the list in LSP and guard the new symbol kinds using a capability.
gerdleon commentedon Sep 27, 2022
I would very much appreciate this.
gerdleon commentedon Sep 27, 2022
To support languages that describe database structures
tablewould be useful.kraigher commentedon Feb 19, 2023
I wrote a proposal here #1186 (comment) that avoids the need to collect a long list symbol kinds globally.
yyny commentedon Apr 21, 2024
Label, for C/C++/Zig/JavaScript/Lua/Assembly/LLVM/etc. labels.travkin79 commentedon Apr 16, 2026
DestructorLanguages like C/C++ need a distinction between constructor and destructor, so adding
DestructortoSymbolKindwould improve the UI (see also CDT LSP issue eclipse-cdt/cdt-lsp#608).Another option would be to use
SymbolTagsto annotate methods as destructors or constructors, similar to PR #2003 using symbol tags to annotate document symbols with details like public, static, final, and other flags / keywords. In this case I would deprecateSymbolKind.Constructorin favour of a newConstructorsymbol tag (and of course also aDestructorsymbol tag).