Language-server-protocol: Collect new SymbolKinds

[dbaeumer]

Collects new symbol kinds.

[vladdu]

I assume it's best to propose one item per comment, so that people can vote for it.

[vladdu]

• pragma / directive

[vladdu]

• macro

[rictic]

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]

Value: There is CompletionItemKind.Value, but no SymbolKind.Value

[tsmaeder]

Annotation

[raja-s]

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.

[raja-s]

Type for type declarations.

[raja-s]

Parameter/Argument to be able to distinguish function/constructor/... parameters from actual variables.

[kenkangxgwe]

Section for typesetting languages

[dbaeumer]

@kenkangxgwe can you provide me with an example.

[kenkangxgwe]

@dbaeumer
In LaTeX,

\section{Introduction}
%...

In Wolfram Language

(* ::Section:: *)
(*Introduction*)

In MATLAB

%%Introduction
// ...

In C#
```C#

region section

// ...

endregion

```

[KamasamaK]

Markdown also has sections. The VS Code built-in extension is currently using SymbolKind.String for them.

[movie-travel-code]

Should provide a symbol kind for the type alias?

go code as bellow.

type DogName = string

swift code as bellow.

typealias DogName = String

[anton-dessiatov]

That's pretty much Haskell-specific, but we could have a pattern symbol kind?

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 Function for pattern synonyms, but for the sake of correctness it would be nice to have a special kind.

[DanTup]

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. Clients will show default icons which may be less appropriate than reusing other icons (for example the VS Code "Class" looks better for extension classes and mixins than the default icon)
2. No guidance is given on the values - if we put them after the existing values, it's possible the spec will gain new ones. Should we just pick arbitrary large numbers?

[DavidGoldman]

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. Clients will show default icons which may be less appropriate than reusing other icons (for example the VS Code "Class" looks better for extension classes and mixins than the default icon)
2. No guidance is given on the values - if we put them after the existing values, it's possible the spec will gain new ones. Should we just pick arbitrary large numbers?

+1 to adding extension support to LSP's SymbolKind, potentially with a differentiator between Interface extensions and Class/Struct (implementation) extensions.

Objective-C itself contains categories which are widely used:

@interface MyClass : NSObject
@property int foo;
@end

@interface MyClass (CategoryAddingNewMethod)
- (void)doSomethingWithFoo;
@end

@implementation MyClass (CategoryAddingNewMethod)
- (void)doSomethingWithFoo {
  NSLog(@"Foo: %@", @(self.foo));
}
@end

and Swift contains extensions, which are also widely used:

class MyClass {
  var foo: Int
}
extension MyClass: SomeProtocol {
  func someMethodForProtocol {
    print("hi")
  }
}

[matklad]

@dbaeumer macro has quite a few upvotes, seems pretty uncontroversial to add, and does not really map to any of the existing symbol kinds.

What's the process for actually adding it to the protocol? I'd love to use it for rust-analyzer

[dbaeumer]

@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 :-)

[DavidGoldman]

Friendly ping, is this still on the radar?

[dbaeumer]

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.

[matklad]

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]

@matklad this is about SymbolKind and not about semantic tokens.

[matklad]

Oh, my bad, I confused both SemanticTokenType with SymbolKind, and server with client, sorry about that :facepalm:

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.

[sam-mccall]

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)

[dbaeumer]

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, ..

[KamasamaK]

@dbaeumer

So I would rather have a SymbolModifier which says static, async, ..

Did you mean SymbolTag?

[dbaeumer]

@KamasamaK yes sorry. Was confused with semantic tokens.

[sam-mccall]

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!)