More types for CompletionItemKind enum

[rkeithhill]

And then add an appropriate icon to display in completion lists. The PowerShellEditorServices extension helps the user auto-complete paths. When you have a list of folder contents it is very helpful to have an icon to distinguish between files and folders.

Compare this UI from VSCode for path completion:

To the UI from PowerShell ISE:

Having a nice, flat icon for a folder would be very nice to show in this list.

[daviwil]

Agreed, this would be great to have!

[jrieken]

@bgashler1 fyi

[jrieken]

related #4201

[jrieken]

• Folder/Directory
• Event (Add Event into CompletionItemKind enum #5407)

[Jerry-Hong]

@jrieken Can I use it now?

[jrieken]

@Jerry-Hong If by it you mean the currently existing ComplemtionItemKind member "yes". Otherwise you have to wait until this issue is resolved ;-)

[DustinCampbell]

Looking forward to this.

[DustinCampbell]

And FWIW, it'd be great to get several more of the icons from VS. We use many of these for C# in VS completion and finding analogs in VS Code is always a bit of a compromise.

Here are icons for which there is no good representation in VS Code's CompletionItemKind:

• Event
• Struct
• Delegate
• Extension method
• Constant
• Enum member
• Operator
• Type parameter
• Versions of all icons with accessibility overlays (e.g. private, protected, internal, etc.)

Here's the basic list of what we use in completion: https://github.com/dotnet/roslyn/blob/master/src/Features/Core/Portable/Completion/CompletionTags.cs

This is the level of detail we use for Visual Studio: https://github.com/dotnet/roslyn/blob/master/src/Features/Core/Portable/Shared/Extensions/ISymbolExtensions_2.cs#L14-L169

It'd be great if I could replicate the icons in VS Code.

[jrieken]

Yeah, our plan is to allow for custom icons

[DustinCampbell]

cc @chrisdias

Please excuse the sarcasm in my response below @jrieken. I will buy whatever beers are needed to make up, but I need to make a point.

I suppose that would address the problem in some sense. However, it does seem a bit weird that we'd be providing "custom" icons from Visual Studio to workaround the issue that Visual Studio Code doesn't provide the appropriate Visual Studio artwork to support a Visual Studio language. It's seriously weird that Visual Studio artwork is provided for "Enum" while the Visual Studio artwork for "Enum Member" is not included. Rather than fix the oversight, the solution is to force all language extensions to provide that artwork (which would be Visual Studio's artwork if they want to stay consistent) themselves? I thought that Visual Studio Code had intended to standardize on the look and feel of Visual Studio at one point. Does that not include standardizing on important pieces of artwork that are included in the Visual Studio family of products?

Will custom icons be supported by the language server protocol if we choose to implement that at some point? If not, how will extensions that provide Visual Studio language support for Visual Studio Code via the language server protocol (e.g. C++) be able to implement completion in a way that is Visual Studio-grade?

Even TypeScript provides overlays for member accessibility in Visual Studio (using the same artwork C# and other languages in Visual Studio do).

However, it can't do the same in Visual Studio Code:

[jrieken]

Sorry that I have ruined your morning ;-).

I guess my previous comment was a bit too short and didn't explain enough. Saying that we will eventually allow for custom icons doesn't exclude adding more default icons. However, the problem is unbounded and currently we are caught in a catch up game. There is no answer to what the full set of icons is, so we can either keep it simple (like an enum member is just a member), allow for custom icons, or keep adding more icons.

Talking about the language server protocol and other editors I honestly don't know what's best: Think of the icon for 'extension method' which isn't a frequently occurring feature in programming languages. Will someone draw an icon that fits into Atom and Sublime? Will someone just copy the icons we ship? Will an existing icon be overloaded/reused, say 'method'?

So far we have been guided by a somewhat fuzzy 'common denominator' approach to fit most programming languages and things like access modifiers fit nicely into that but it also means we cannot cover everything from any language.

[DustinCampbell]

Oh, you didn't ruin my morning at all Joh. 😄

I'm willing to be part of any conversation about determining the 'common denominator' set of icons. I even promise to not push for making the common denominator just the set required by C#. 😄

[jrieken]

Perfect. We are now in the Jan endgame. I'll schedule this for Feb and get in touch with you when it's time.

[DustinCampbell]

Sounds good. You might want to include @markw-t from the VS editor team as well.

[markw-t]

Thanks for the add guys. It makes perfect sense to me that Visual Studio Code extenders would be able to create parity experiences to Visual Studio without creating custom art - a single "Visual Studio Family" experience should be possible in completion lists like this as @DustinCampbell suggests above; so the Visual Studio Code default set should include all the values found in the Visual Studio enum if possible.

[jrieken]

Sorry, this has slipped. Blame me for being on vacations 🌴. Moving to March

[jrieken]

Let's start to tackle this by adding some more common-denominator icons. I'd like to propose that we for now leave the modifier icons out of the equation. It's a little unlucky that we have called it CompletionItemKind and SymbolKind and I have the feeling we shouldn't add all variants in there but add the concept of a KindModifier such that both can determine the visual representation of something.

For the set of common icons we have things like Snippet, Color or File that describe more or less literals and things that occur in programming languages, like Function or Interface. In #2628 (comment) @DustinCampbell suggests to add more icons to the latter bucket which is OK with me as long as we don't make it too specific for a single language.

Can we come with a N-programming-languages-have-this-rule? For instance, more than N programming languages support interfaces so we have CompletionItemKind.Interface. Unsure what N should be, for sure N > 1 maybe something around 3-5 of the most commonly used languages.

[jrieken]

• added enumeration member as vscode.CompletionItemKind.EnumMember. Should go together with CompletionKindKind.Enum. N-languages-have-this-rule justification: C, C++, C#, Swift, TypeScript, Java etc...

[DustinCampbell]

Extension Method makes sense to leave off. Event is the one I'm probably most interested in. I figure that's probably used a ton since it appears in all the .NET languages (i.e. C#, F#, VB, PowerShell, etc.) plus other languages like HTML:

[jrieken]

True - I have forget that one.

[jrieken]

Added 'Event' and 'Operator', unsure what icon to use for TypeParam. fyi @aeschli about the Event completion kind and above sample

[DustinCampbell]

The one we use for C# and Visual Basic in VS looks like this:

I think C++ uses something different.

[jrieken]

I have found this one which fits Foo<T> but also reminds me of a word processor...

[DustinCampbell]

I might be wrong, but I think that's what C++ uses for templates. For us, that always felt a little "on the nose", if you get my meaning. A little too precise. That said, I'm comfortable with what you decide to pick.

[jrieken]

I understand, and the icon is labeled as template but I couldn't find the T-icon. Nothing we cannot change later, what matters is that the kinds are exposed in the api

[DustinCampbell]

I haven't looked in the image library in awhile, but if it helps, C# uses the image indexed by GlyphGroupType in Microsoft.VisualStudio.Language.IntelliSense.StandardGlyphGroup.

[jrieken]

Closing this since we now have these completion item kinds. We can still change icons via separate issues. Happy Coding!

[DustinCampbell]

Thanks for your work here @jrieken! I'm really looking forward to using these.

[chrmarti]

LGTM, verified. (Note that the lists are not identical, I assume that's by design.)

[DustinCampbell]

@jrieken: Any idea when these icons will make their way into the LSP?

[jrieken]

@dbaeumer will know

[dbaeumer]

Created microsoft/language-server-protocol#324

[DustinCampbell]

Thank you sir!