-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
Allow for [Completion|Symbol]Kind modifiers #23927
Comments
cc @kieferrm |
More modifier candidates are: deprecated, experimental |
For C/C++, we would like "declaration", "private", and "protected". |
Different options
I am in favour of option 2 but I am unsure if we should have two Adding @mjbvz for feedback |
Yes I prefer option 2 as well. Here's what some other projects do:
From an api point of view, I like the TypeScript approach that uses an array of modifiers:
That way an extension could mark a completion as |
Hm, I was thinking about a bitmask but an array might be JavaScript-like. This also compares to
@sean-mcmanus I don't think we wanna be the fine grained. Generally, we have to walk the fine line of finding a good enough abstraction that describes the our UX and that still fits most programming languages. |
Current proposal (due to TypeScript gymnastics the name is export enum CompletionItemKindModifier {
Deprecated = 1
}
export interface CompletionItem {
/**
*
*/
kind?: CompletionItemKind | { base: CompletionItemKind, modifier: ReadonlyArray<CompletionItemKindModifier> };
} |
Actually, instead of "modifier" we could use "tags". That term is less overloaded when it comes to programming lingo (and it also matches DiagnosticsTag). So, have @mjbvz Preferences? Likes? |
I like “tags”. It’s more open ended. If we call it “tags” does it still make sense to put this as a property on “kind”? Or should it be it’s own field? |
Good question... I have choosen the current approach so that we don't have tags without (base) kinds. E.g an item could only be tagged as |
It's not like this export enum CompletionItemKindTag {
Deprecated = 1
}
export interface CompletionItem {
kind?: CompletionItemKind | { kind: CompletionItemKind, tags: ReadonlyArray<CompletionItemKindTag> };
} The alternative, with tags as it own field would be this export enum CompletionItemTag {
Deprecated = 1
}
export interface CompletionItem {
kind?: CompletionItemKind;
tags?: ReadonlyArray<CompletionItemTag>
} |
Prefer the alternative,
I feel even if you can't makeup your mind to provide a |
Went with the kind approach and I actually quite like it. I thinks its flexible and expressive enough. These are all the proposed changes to cover suggestion, outline, and workspace symbols export enum SymbolTag {
Deprecated = 1
}
export interface SymbolInformation {
/**
*
*/
tags?: ReadonlyArray<SymbolTag>;
}
export interface DocumentSymbol {
/**
*
*/
tags?: ReadonlyArray<SymbolTag>;
}
export enum CompletionItemTag {
Deprecated = 1
}
export interface CompletionItem {
/**
*
*/
tags?: ReadonlyArray<CompletionItemTag>;
} |
Moving to September for finalisation |
Verifier: use the vscode-dts-utility to use the latest version of |
extracted from #2628
In completions and for symbols we allow to provide a kind which is mostly use to derive an icon. For instance
vscode.CompletionItemKind.Method
. This issue is about allowing to modify these kinds to expressing that something is a "private member" or an "abstract protected method"The idea is that we don't add more and more kinds, e.g no
CompletionItemKind.PrivateMethod
but a second type, a kind-modifier, that works in combination with a kind.Potential candidates are: public, protected, internal, package-private, friend, private, static, final, const, abstract, volatile, transient, ... A "n languages have this"-rule should be applied when picking candidates.
The text was updated successfully, but these errors were encountered: