Completion item kinds customization support V2

[nferhat]

Basically a better version of #9996, avoiding useless allocations and hacky code (hopefully) in order to achieve this feature

This PR allows the user to customize the kind text shown inside the completion menu, allowing the end user to do the following:

• Change the colors of each kind individually, helping with readability of the menu
• Change the displayed text of each kind, allowing for example the use of icons/pictograms. By default helix uses the kind name in kebab-case, the user can override with for example: editor.completion-item-kinds.type-parameter = "..."

[David-Else]

Brilliant! Could you add a preset in the documentation to use Nerd Fonts, like the information you shared in the last PR?

[univerz]

Could you add a preset in the documentation to use Nerd Fonts

this screams "icons api"

[nferhat]

Could you add a preset in the documentation to use Nerd Fonts

this screams "icons api"

With such an API we could maybe complement the path completion too? Would be pretty cool!

[David-Else]

I meant just add the equivalent of the following from the last PR into the documentation so people can copy and paste it, changed to work with this PR. I don't see any documentation in this PR yet.

completion-item-columns = ["kind", "name"]
[editor.completion-item-kinds]
text = ""
method = ""
function = ""
constructor = ""
field = ""
variable = ""
class = ""
interface = ""
module = ""
property = ""
unit = ""
value = ""
enum = ""
keyword = " "
snippet = ""
color = ""
file = ""
reference = ""
folder = ""
enum_member = ""
constant = ""
struct = ""
event = ""
operator = ""
type_parameter = ""

An "icons API" would be cool, but probably in another PR, this one is so nice and simple I hope it can be merged asap!

[nferhat]

With this latest commit theming now works!

[nferhat]

This works now, but when adding new sources, compute_completion_item_kind_styles must be changed. I'll see how I can tackle this

[nferhat]

I meant just add the equivalent of the following from the last PR into the documentation so people can copy and paste it, changed to work with this PR. I don't see any documentation in this PR yet.

completion-item-columns = ["kind", "name"]
[editor.completion-item-kinds]
text = ""
method = ""
function = ""
constructor = ""
field = ""
variable = ""
class = ""
interface = ""
module = ""
property = ""
unit = ""
value = ""
enum = ""
keyword = " "
snippet = ""
color = ""
file = ""
reference = ""
folder = ""
enum_member = ""
constant = ""
struct = ""
event = ""
operator = ""
type_parameter = ""

An "icons API" would be cool, but probably in another PR, this one is so nice and simple I hope it can be merged asap!

Sure, where should this kind of recipe/example should go inside the docs?

[David-Else]

Sure, where should this kind of recipe/example should go inside the docs?

In the editor config I think, there are lots of example configs already: https://docs.helix-editor.com/editor.html

[nferhat]

Documentation finished!

@David-Else ready for review

[David-Else]

I have changed the wording to hopefully make it clearer, please let me know if I have understood your original meaning correctly. You might want to mention the fact they can be styled and link to the theming documentation?

[David-Else]

I am using the VS Code codicons included with Nerd Fonts and started styling their colors to match my dark_plus VS Code theme! I will release a full version of my theme including the new styles when this is merged :) Here is a preview of Helix using it (I like having the text as well as the icon):

[nferhat]

Hey! Review and merging would be appreciated!

I would also like to know if #12299 merged with this still works properly!

[RoloEdits]

Wouldn't it make more sense to put the config under lsp? This way there could be one place to source icons from. For example, a breadcrumb feature could access the same symbol information and get the icons from the config. I bring this up because this something i've missed and have been thinking about implementing. If you have configs here for the just for completion icons, then that feature would need to have its own separate icon list, or just spaghetti-code off of the completion icons.

Something like:

[editor.lsp.symbol-icons]

[nferhat]

Wouldn't it make more sense to put the config under lsp?

I don't think so, since these icons are not exclusive to LSP and could apply to any source that gets implemented in helix (for now we only have the LSP and path ones)

Though I still think a better name for the icon would be pretty nice.

[univerz]

Wouldn't it make more sense to put the config under lsp?

I don't think so, since these icons are not exclusive to LSP and could apply to any source that gets implemented in helix (for now we only have the LSP and path ones)

+ there are several other PRs whose sole purpose is to display (nerdfonts) icons in various places. helix has done many things significantly better than other editors, #2869 might be another one.

[nferhat]

Wouldn't it make more sense to put the config under lsp?

I don't think so, since these icons are not exclusive to LSP and could apply to any source that gets implemented in helix (for now we only have the LSP and path ones)

• there are several other PRs whose sole purpose is to display (nerdfonts) icons in various places. helix has done many things significantly better than other editors, feat: icon support #2869 might be another one.

The better thing would be to have this integrated with this kind of icon API PR, but such had become stale and outdated regarding the code base. I just implemented this the simplest way possible, though a larger-scale icon integration with the editor is the better way to go

[RoloEdits]

The issue with the old icons PR is that it had a problem of scale in the toml. At first it was a separate file from the config, and then just merged into the config file, which the maintainers didn't like (Let alone the config will switch to some scheme config in the future), it was still too many options.

But with this, its sort of a smaller portion of the same issue. If one person adds icon support for the version control on the status bar, and you add icons for the completion menu, and I add icons for a breadcrumb, and someone else add icons for the file explorer, and someone else adds for the file type on the status bar, you end up with overlap of having to fill out the toml with the same thing.

I think the maintainers might have issue with the same mountain that the icons api PR was even in pebble form, as that would be the trend that all these PRs lead to. Having to put the same icon in 3 different spots on the toml is not something I also want to do either.

If the icons here are only for lsp things, then the thought is to put them in the lsp part, as other things that can use them can, and it will all cascade. Scaling this way would merge path and the file icons as they would use the same set, representing directories and filetypes. Diagnostics would have their own, as another open PR is trying to get merged.

I think this covers like 99% of things id ever want icons for, and its just four domains (Though the GITY/VCS is really just one thing): LSP icons, Diagnostic Icons, and Path/File icons. This scales much better in toml and any new implimentation can piggyback already existing configs.

I only bring this up now because I can see this potentially becoming a reason why the maintainers dont merge these things using the same reason as they didnt merge the icons pr, which I dont want.

[RoloEdits]

This is where I would love to see a maintainer help coordinate some efforts to make an acceptable "api" for these things. Or merge multiple prs into one with the config implimentation that best works.

I think even something like this could work, and then just a matter of propagating where needed, and it keeps the scope well defined:

[icons.lsp]
[icons.path]
[icons.diagnostic]

[univerz]

the great thing about icons PR is that it includes defaults, so there is no need to share them in documentation/copy-paste from comments and keep them up to date + it's easy to turn them on/off.

icons are similar to themes - most people don't have the artistic ambition to set hundreds of values ​​in a configuration file.

[RoloEdits]

Except themes are just colors. Icons more often than not require patched fonts. If I recall correctly it was also an issue of how to handle not everyone having them. Having done a lot of starship configuring, I can say that I dont use every possible patched icon font. I only ever deal with a small subset of filetypes, for example. I have only changed what I come across.

Having defaults that everyone should be able to display, like what the diagnostic PR is doing iirc, and then offering the potential to override, is something that this project as a whole has been geared towards. Also something starship does, and it seems to work out for them.

[univerz]

Icons more often than not require patched fonts. If I recall correctly it was also an issue of how to handle not everyone having them.

#2869 (comment)

Having defaults that everyone should be able to display, like what the diagnostic PR is doing iirc, and then offering the potential to override

that's exactly what's great about icons PR - it treats icons as first-class citizens (not just as a byproduct of being able to manually override a few values) so they can have their own (nerdfonts) defaults ​​too.

[RoloEdits]

Mashed together #12369 as a proof of concept that I can take further, but just wanted to get the idea across. Any discussions can take place there so as not to hijack any one PR ( apologies @nferhat )

[darshanCommits]

@RoloEdits Agree on the sentiment that this is something maintainers help would befit.

also your earlier suggestion regarding editor.lsp.symbol-icons I don't think that's a good approach as completion engine is more than just for LSP, namely path, buffer, snippet, dictionary etc. it'll also have awkward namespace if went this direction like

path.icons buffer.icons?? Where will these go, surely not in lsp.symbol-icons.path

Anyway, the latter approach seems more contained and portable.

[icons.lsp]
[icons.path]
[icons.diagnostic]

And pretty solid and extensible too
icons.lsp.enable
icons.nerdfont-fallback.enable which would use the predefined icons in the default config if nerdfont not available.

[nferhat]

Mashed together #12369 as a proof of concept that I can take further, but just wanted to get the idea across. Any discussions can take place there so as not to hijack any one PR ( apologies @nferhat )

Nah you didn't hijack my PR, I'm cool with that

Interesting proof of concept though, hope you can take it further!