You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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').
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.
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 :-)
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.
Johannes Rieken (@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.
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.
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?
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.
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.
Activity
vladdu commentedon Nov 27, 2017
vladdu commentedon Nov 27, 2017
rictic commentedon Nov 27, 2017
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 commentedon Nov 29, 2017
There is
SymbolKind, but noCompletionItemKindforNamespacesmarter commentedon Nov 20, 2018
There's SymbolKind.Package, but not CompletionItemKind.Package
kdvolder commentedon Nov 21, 2018
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 commentedon Dec 18, 2018
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 commentedon Dec 18, 2018
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 commentedon Dec 19, 2018
Will do :-)
Johannes Rieken (@jrieken) do you think
macroanddirective/pragmais something we would like to VS Code as well. They are for sure useful for C/C++jrieken commentedon Dec 19, 2018
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.
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 commentedon Dec 19, 2018
Fair point. The language I know that have these concepts are:
kdvolder commentedon Dec 19, 2018
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:
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 commentedon Dec 19, 2018
I see the point for DSLs. For programming languages I do prefer consistency and not different icons for every programming language I use.
kdvolder commentedon Dec 20, 2018
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 commentedon Dec 20, 2018
I am fully open to have both.
razzeee commentedon Apr 25, 2019
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
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 commentedon Nov 13, 2019
For C++ TypeDef would be helpful as well.
slrtbtfs commentedon Nov 14, 2019
Label
floitsch commentedon Jul 21, 2020
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
dynamictype 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
typedefcase too.KamasamaK commentedon Jun 28, 2021
UserandIssuewere added to VS Code (see microsoft/vscode#91541) so should be simple additions.dbaeumer commentedon Jan 8, 2024
From #1872
Add Instruction and Register
cdietrich commentedon May 8, 2024
typefor (primitive) types