-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collect new SymbolKinds #344
Comments
I assume it's best to propose one item per comment, so that people can vote for it. |
|
|
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. |
|
Annotation |
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 |
|
|
|
@kenkangxgwe can you provide me with an example. |
@dbaeumer \section{Introduction}
%... In Wolfram Language (* ::Section:: *)
(*Introduction*) In MATLAB %%Introduction
// ... In C# #region section
// ...
#endregion |
Markdown also has sections. The VS Code built-in extension is currently using |
Should provide a symbol kind for the go code as bellow. type DogName = string swift code as bellow. typealias DogName = String |
That's pretty much Haskell-specific, but we could have a There is a GHC Extension named PatternSynonyms that enables syntax for sort-of-first-class patterns like this: data Type = App String [Type]
pattern Arrow t1 t2 = App "->" [t1, t2]
pattern Int = App "Int" [] The lack of dedicated symbol kind It's not that big of a problem, currently Haskell Language Server happily uses |
Dart is adding extension classes, and currently we're having to send SymbolKind=Class to avoid VS code using a default icon. It'd be nice to have some ability to have Extension classes and Extension methods better supported (either as kinds, or modifiers). There are other comments here suggesting we should just make our own up, but the concerns with that are:
|
+1 to adding Objective-C itself contains categories which are widely used:
and Swift contains extensions, which are also widely used:
|
@matklad for 3.16 we can make a push to add new kinds. I will synchronize with VS Code as well otherwise they will not be rendered nicely :-) |
Friendly ping, is this still on the radar? |
I checked with the VS Code team and there are currently no plans to add new symbol kinds. To work on this and propose new once we need a client that implements so. Otherwise only having them in the spec with no implementation is not very helpful. |
This list ( |
@matklad this is about |
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 |
They're valuable once implemented in both server and client, so there's a first-mover disadvantage. (FWIW I'd be eager to add both server and client support for |
IMO |
Did you mean |
@KamasamaK yes sorry. Was confused with semantic tokens. |
Since this enum can't be extended by clients/servers, it would be useful to have 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. |
I would very much appreciate this. |
To support languages that describe database structures |
I wrote a proposal here #1186 (comment) that avoids the need to collect a long list symbol kinds globally. |
|
Collects new symbol kinds.
The text was updated successfully, but these errors were encountered: