Repository navigation
Enum members do not use EnumMember SymbolKind #2945
Description
Describe the bug
There are some inconsistences of VSCode SymbolKind for building extensions.
To Reproduce
I've forked the https://github.com/alefragnani/vscode-separators VSCode extension to add more separators (the original code only works on SymbolKind.Method, SymbolKind.Function and SymbolKind.Constructor). This extensions draws a line separating methods on any VSCode supported language.
While working on it to add more places where separators are placed, there are some minor inconsistences, as follow:
The extension is filtering i.SymbolKind.Method, i.SymbolKind.Function, i.SymbolKind.Constructor, i.SymbolKind.Class, i.SymbolKind.Enum, i.SymbolKind.Interface, but:
There is a SymbolKind.EnumMember and a SymbolKind.Enum. I'm requesting only SymbolKind.Enum but the screenshot shows separators on each member.
(A question: extension ModuleExtension on Module { should trigger which SymbolKind?)
The SymbolKind.Method (or .function) leaves the @override attribute outside the method itself. I don't know how the definition of SymbolKind works, but would be nice if the SymbolKind.Method (or really any of them) considerer the starting point before the attributes (so the line would be draw above the @override).
(Another question: when using SymbolKind.Property, a separator is drawn before get and another before set. It would be awesome if a pair of get/set should trigger SymbolKind.Property only once, to get only one separator for the pair).
Versions (please complete the following information):
- VS Code version: 1.51.0
- Dart extension version: 3.16.0
- Dart/Flutter SDK version: 1.22.3
Activity
DanTup commentedon Nov 10, 2020
There are a few things here, so I'll try to answer them all!
1.
Enummembers don't useEnumMemberThat's a bug/oversight. The original LSP spec didn't have
EnumMemberso it should only be provided when a client advertises support. I've got a fix at https://dart-review.googlesource.com/c/sdk/+/171286/ (I believe the non-LSP version was already updated, but LSP was not).2.
extension ModuleExtension on Module {should trigger whichSymbolKind?Looking at the code, I believe this will return
Namespace. It's not perfect, but I think it was the closest match from the specified options.3. The
SymbolKind.Methoddoesn't include the@overrideattributeThis is expected. The symbol data being used here is not really intended for what it's being used for - it's what populates the Outline tree and the Document Symbols list. If we were to include the
@overrideand newlines in the symbol, the tree and symbol list would not work as intended (for example each method tree node might just show@overrideif the client truncates/clips at the newline).4. It would be awesome if
get/settriggered only oneSymbolKind.PropertySimilar to 3, this isn't really possible without breaking other things (and providing data in a way that LSP servers are not expected to). The best option would be to customise the extension to have some way to fold these together if they're next to each other.
I think that's everything, but let me know if I overlooked anything. I'll treat this issue as being for the first, since the others are questions or things I don't think we can really address in the LSP data.
Thanks!
[-]SymbolKind inconsistences[/-][+]Enum members do not use EnumMember SymbolKind[/+][Analyzer] Use SymbolKind.EnumMember when client supports it
DanTup commentedon Nov 10, 2020
Fixed in dart-lang/sdk@d4e5a14.