Collect new CompletionItemKinds

[dbaeumer]

Collects new completion item kinds.

[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]

There is SymbolKind, but no CompletionItemKind for Namespace

[smarter]

There's SymbolKind.Package, but not CompletionItemKind.Package

[kdvolder]

This is futile, server should be able to define their own completion kinds. There's no way you are going to be able to enumerate all possible completion kinds in the world. Especially if you are defining a language server for a dsl it seems unreasonable to bake your domain terminology into the LSP spec. (The item kinds would be specific to the language domain and could be things like , 'task', 'job', 'pipeline', 'resource').

[dbaeumer]

The symbol item kind is to my knowledge only used to pick an icon. There is no semantic bound to it. If we make this an open set then clients only might show a default icon for it which is fine for me.

[kdvolder]

Or... server must be able to provide icons somehow. But yes, I understand how that may not naturally blend with the look and feel of every client.

I suppose having a growing list of 'standard' kinds is still helpful. Probably doesn't help with DSL languages but at least there's a larger set of 'good looking icons' to pick from. Maybe I was a bit harsh calling this 'futile'. So please do carry on enlarging the list :-)

[dbaeumer]

Will do :-)

@jrieken do you think macro and directive/pragma is something we would like to VS Code as well. They are for sure useful for C/C++

[jrieken]

Or... server must be able to provide icons somehow. But yes, I understand how that may not naturally blend with the look and feel of every client.

That. The fear is that it will look horrible because every editor has a different style. On other hand we also don't want editor authors to have to provide 100s of icons.

@jrieken do you think marco and directive/pragma is something we would like to VS Code as well. They are for sure useful for C/C++

In VS Code there is a shared subset approach and the rule of thumb is that there are no 1-offs for one language but that you have name five other languages that have the concept.

[dbaeumer]

Fair point. The language I know that have these concepts are:

• C/C++
• Lisp
• C# (has #ifdef, but not macros)
• Assembler languages :-)

[kdvolder]

Not to outright dismiss the idea of a server contributing icons. Might it not go a long way with a few simple guidelines? Something like:

• icons should be on transparant background (so they can look good with range of different bg colors)
• icons should be provided in pairs, one icon to be used for 'light' themes, one for 'dark' themes (to ensure enough contrast with the editor's theme)
• maybe add some rules about icon resolution and file formats (to avoid experiences of pixelated server-provided icons being mixed in with more high-quality native ones).

I think that would probably be enough for the icons to look pretty good and not totally out of place.

I'd say this is probably better/preferable to have all your DSL concepts be represented with only a single generic completion icon.

[dbaeumer]

I see the point for DSLs. For programming languages I do prefer consistency and not different icons for every programming language I use.

[kdvolder]

Yes, DSLs is what I am personally mostly thinking about. And just extending the list of standard identifiers won't help much there (clearly, adding every noun in the dictionary as a 'standard kind' and creating icons for them all is not practical).

So, having a long list of 'standard' kinds explicitly listed in the spec is good. But so is having a mechanic by which non-standard kinds can have their own icons contributed by the server. So why couldn't we have both?

[dbaeumer]

I am fully open to have both.

[razzeee]

Hey, I got here searching for docs on what's the best approach for symbolkinds, if we should feed everything we have and if I should map stuff that doesn't fit to something else that's similar. https://github.com/Razzeee/elm-language-server/issues/11

The symbol item kind is to my knowledge only used to pick an icon. There is no semantic bound to it. If we make this an open set then clients only might show a default icon for it which is fine for me.

When testing what I got so far, some symbolKind lead to different codelenses being provided in my vscode. Might me another plugin, like gitlens. Just wanted to let you know.

[dbaeumer]

For C++ TypeDef would be helpful as well.

[slrtbtfs]

Label

[floitsch]

Named arguments / parameters. (https://en.wikipedia.org/wiki/Named_parameter). Once the call is resolved, the LSP server can often suggest names for the arguments.

I'm also missing a more generic (catch-all) "Type" kind. For example, the dynamic type in Dart: it's neither a keyword (a local can be named "dynamic"), nor a class or an interface. Similarly, this could be used for enum types. An enum type is (depending on the language) not a class or interface. I would also not know which type to use for a function type. Again: neither a class nor interface. Could be used for the typedef case too.

[KamasamaK]

User and Issue were added to VS Code (see microsoft/vscode#91541) so should be simple additions.

[dbaeumer]

From #1872

Add Instruction and Register

[cdietrich]

type for (primitive) types