Repository navigation
More types for CompletionItemKind enum #2628
Description
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.
Activity
daviwil commentedon Feb 2, 2016
Agreed, this would be great to have!
jrieken commentedon Feb 2, 2016
Brad Gashler (@bgashler1) fyi
jrieken commentedon Mar 16, 2016
related #4201
[-]Add Folder (or Directory) to the CompletionItemKind enum[/-][+]More types for CompletionItemKind enum[/+]jrieken commentedon May 25, 2016
Jerry-Hong commentedon Jul 17, 2016
Johannes Rieken (@jrieken) Can I use it now?
jrieken commentedon Jul 20, 2016
JerryHong (@Jerry-Hong) If by
ityou mean the currently existingComplemtionItemKindmember "yes". Otherwise you have to wait until this issue is resolved ;-)DustinCampbell commentedon Jan 24, 2017
Looking forward to this.
DustinCampbell commentedon Jan 24, 2017
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:
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 commentedon Jan 25, 2017
Yeah, our plan is to allow for custom icons
DustinCampbell commentedon Jan 25, 2017
cc Chris Dias (@chrisdias)
Please excuse the sarcasm in my response below Johannes Rieken (@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 commentedon Jan 25, 2017
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.
34 remaining items
DustinCampbell commentedon Apr 19, 2017
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 commentedon Apr 19, 2017
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 commentedon Apr 19, 2017
I haven't looked in the image library in awhile, but if it helps, C# uses the image indexed by
GlyphGroupTypeinMicrosoft.VisualStudio.Language.IntelliSense.StandardGlyphGroup.jrieken commentedon Apr 21, 2017
Closing this since we now have these completion item kinds. We can still change icons via separate issues. Happy Coding!
DustinCampbell commentedon Apr 21, 2017
Thanks for your work here Johannes Rieken (@jrieken)! I'm really looking forward to using these.
chrmarti commentedon Apr 26, 2017
LGTM, verified. (Note that the lists are not identical, I assume that's by design.)
DustinCampbell commentedon Oct 24, 2017
Johannes Rieken (@jrieken): Any idea when these icons will make their way into the LSP?
jrieken commentedon Oct 25, 2017
Dirk Bäumer (@dbaeumer) will know
dbaeumer commentedon Oct 25, 2017
Created microsoft/language-server-protocol#324
DustinCampbell commentedon Oct 25, 2017
Thank you sir!