feat!: add basic support for icons #12369
Conversation
|
@darshanCommits Taking the discussion here. Yeah, I agree with the groupings, just need to figure out how that will go. As we dont really have snippets in full form, like no manager, and that I dont really use them, I think just one icon would also suffice? like a Currently I am using |
|
Also let it be known that I don't really use icons, or I guess feel the need to use them, but am trying to get in front of an issue with a solution. This is basically an RFC. I think at most I would only mess with the vcs icon, which I do now my using the separator option. I dont ever use the bufferline. And maybe the statusline filetype. I dont feel the need to have them in the file picker or the path completion, I think the recent theming is enough for me, so if this goes anywhere, I might leave that to someone else to do after the fact. |
At first I wasn't fully sold on this but now this doesn't seem bad. Laying the infrastructure to do all that seems good idea. Specially with the language icons. And a follow up PR for non-nerdfont vcs and completion icons(not LSP, just if it's coming from path, buffer, snippet or ls) were default that would be it for me already, which could also serve as fallback if nothing is defined in the editor.icons. And diagnostics, color works for me tbh, but since color is not the most accessible indicator, might as well have that in default. Reason as to why would be accessibility, every other form of icon, to me personally is more of an aesthetic decision. Rest of the work is better off delegate to user, or more precisely imo, to plugins in the far future. |
|
Cool stuff, wish to see this evolve into something |
|
@darshanCommits Yeah, the diagnostic icons are also different, taken from #12060
|
|
I think the part I might like the most here is that there would be no need for another config option to enable or disable the symbols. The out of box experience would be the same, and then adding to the config "adds them". Its entirely opt-in user side. opt-in in perhaps the most complete sense as they will need to go as far as they want to get what they desire. But it puts the burden on them to make sure the fonts they pick render well in their terminal emulator. This is actually why I used |
|
An example config that covers pretty much all my use cases (the lsp ones would be the last thing, in the completion menu or a breadcrumb, for example):
I think it still retains the helix minimal config spirit pretty well. |
|
Gonna open this for review as the main stuff is done, its just a matter of coming up with names and seeing if the concept itself it good. Main questions, besides if this is even an approach that is deemed acceptable, should I move all the editor config stuff over to Im going to leave the work for adding icons to the finder/completion to someone else for later, as its not something I am really sold on. |
|
There should probably be a default for the icons. I can see people copy pasting 400 line icon configurations into their configs, which isn't pretty. Meanwhile we could just have a default for them and people who want to have icons just enable an option |
|
Or alternatively we can have a dedicated file for icon configs It will be treated like themes You can specify in the config like this icon-pack = "nerd"This will load the In this case we won't need an enable/disable option for icons. People can just remove the |
These things are exactly the reason the other icons pr never got merged. And when I see this
My thoughts are to let them do that and maintain it. Like I mentioned before, fonts and terminal emulators are the wild west. Often I need to add an extra space to the right of the font to make them render the right size. Adding 400 icons and everyone running 100 different fonts on 20 different terminal emulators(new one just dropped the other day) sounds like a nightmare to me. |
Ok, honestly just getting this PR merge would already be a win! We can think about any sort of defaults or stuff like that later down the line :) |
|
My thoughts exactly. Its main purpose it to hopefully get out in front of some other PRs that have their own bespoke configs and solve a potential issue of merging those in, rather than them getting stuck on "we don't want any more config bloat". |
|
#2869 (comment): config-per-icon is the granularity we're trying to avoid. "Starter pack" configs or config distributions like this would inspire are antithetical to how we try to expose configuration, even if it means making some things non-configurable. Basic icon support, as far as I read into @archseer's comment, is an icons module (probably toplevel in |
This was that attempt to do these things at once. What I read from it was that the config in that PR allowed things like color changing and a bunch of other things, which is what I took from reading:
The part about hard coded values, to me, was like a stopgap that is simple, as he says its something he would end up needing to own:
As I said above, hard coded values present their own issues with rendering. Its not that someone wants to change the set to another one, as far as configurability, it could be that it doesn't even render correctly for them (too big, small, shifted, etc.).
This is already on the pipeline with #12151, #6646, and #12060. Each PR is implementing their own way to expose icons/symbols to the user through a config. What is the plan for those? If those PRs arent dead in the water, then this only(attempts to) unifies the interface. |
|
The scale of icons I also feel is perceived to be much larger than it really is. Most people arent interacting with all 216 currently supported languages. Which is the largest portion of the potential icons. The screenshot I have of my config, substituting here an there, probably covers 99% of people. |
|
I'm not sure how that "override mechanism" should work exactly and I'm not sure we'll need it at all so I would target the hardcoded values idea instead. We can always introduce more config later if different widths are a problem in practice.
These PRs seem to be consistently created for the purpose of setting an icon - see the description or comment images. Were it up to me alone I would not ever expose this granularity of configuration especially when it comes to cosmetics, and this applies to other cosmetics configuration like #12311 or the numerous PRs about the bufferline. I don't consider cosmetics a priority and I hate adding config options in general though so I may have an extreme opinion here - other maintainers might dissent.
Needing to set 20 config options unrelated to actual functionality seems like way too much to me. |
Its a known problem for me already. If this was to go through, despite me making the PR, it would be unusable for me.
This I think is the strong suit of this implimentation. You can add it if you want. If not, it changes nothing of how helix looks, and it doesn't need to be designed around in the future, which is another issue of hardcoding. And if you happen to only want to change a small subset of things, its clear how you would piecemeal it (with hopefully good naming and a logical abstraction in the config).
I see this a lot as something asked for and a few of the PRs doing them. I mentioned this issue here:
Im not a big icons guy myself, but either those PRs should be closed, or at least told that they wont merge, as this is the same issue here as there. Or if they are merged with no coordination, we have an ad-hoc config issue, which I think is something that no one wants. I agree having good defaults, and that should always be a priority, so I will see if I can think of ways to improve this, look around more and see what other TUIs are doing, but as far as maintenance is concerned, which im most worried about, this is currently only I set my 10 icons and by serendipity find them used later elsewhere without having to change more icons. So in the mode of set and forget. Not a daily back and forth with the config. |
|
Looking around, it looks like |
|
Id also argue that were are already near the maximum upper bound for complexity here as far as "domains" are concerned. The only missing symbols, as far as I can see, are for snippets and the dictionary. Both of which I believe are just one symbol each. Something like a And something like an Im not sure what wouldn't be covered by these, but like I said, I am not really a symbols person. The current literal text works for me just fine. |
|
Just saw icons = {
misc = {
dots = "",
},
ft = {
octo = "",
},
dap = {
Stopped = { " ", "DiagnosticWarn", "DapStoppedLine" },
Breakpoint = " ",
BreakpointCondition = " ",
BreakpointRejected = { " ", "DiagnosticError" },
LogPoint = ".>",
},
diagnostics = {
Error = " ",
Warn = " ",
Hint = " ",
Info = " ",
},
git = {
added = " ",
modified = " ",
removed = " ",
},
kinds = {
Array = " ",
Boolean = " ",
Class = " ",
Codeium = " ",
Color = " ",
Control = " ",
Collapsed = " ",
Constant = " ",
Constructor = " ",
Copilot = " ",
Enum = " ",
EnumMember = " ",
Event = " ",
Field = " ",
File = " ",
Folder = " ",
Function = " ",
Interface = " ",
Key = " ",
Keyword = " ",
Method = " ",
Module = " ",
Namespace = " ",
Null = " ",
Number = " ",
Object = " ",
Operator = " ",
Package = " ",
Property = " ",
Reference = " ",
Snippet = " ",
String = " ",
Struct = " ",
Supermaven = " ",
TabNine = " ",
Text = " ",
TypeParameter = " ",
Unit = " ",
Value = " ",
Variable = " ",
},
},Not sure what |
|
Is there a good example / minimal reproduction of something that wouldn't work correctly as a default? What I've read of that I was suspecting to be speculation but if there are already actual problems with width then an override system like @archseer mentioned could be a part of the "basic support". (On the technical side we would definitely want to use a small string optimization for this type.) But I would disagree with the comments above about not providing a default and requiring configuration for every glyph. |
For me its as simple as removing a space to the right: Ive also had spurious issues with alignment or skewing? Im not really sure how to describe it. Different terminals displayed it differently as well. Which is another issue. I'm on my third Ioskiva Nerd Font(😱) trying to find the best balance of issues.
Yeah that would be the start of my work once I can find a direction to go in.
If we keep the current configure everything way, as the override, then it should be easy enough to just add them to the default impl. And then just add a global override like before. Due to the design where everything is gotten through getters, the propagating should only need to be scoped to those getters. |
|
Ok, did a few here as I wanted to see what scale would look like for a best effort default. 45 file types done. Further toggling can be discussed as we go on. For now it defaults to off, as expected.
|
|
There is no toggle for the diagnostics as we already always use them. They can just be overridden. Same for the breakpoints. |
|
Now only this is needed to get what I have shown before: [editor.icons.vcs]
enable = true
[editor.icons.mime]
enable = trueI added the changes from #12060 making the icons you(@the-mikedavis) were last known using, the defaults. |
what exactly do you mean by that? do you want the whole buffer name tab to be coloured by the icon? or just the space on the left side of the buffer name? |
Right, instead of it being Is that a custom theme you are using? Or is it a built-in? |
it's a custom theme I'm using, it does not inherit from any existing helix themes https://github.com/NSPC911/dotfiles/blob/main/AppData/Roaming/helix/themes/nordic.toml the main part is "ui.bufferline" = {}
"ui.bufferline.active" = { modifiers = ["reversed"] } |
|
An upcoming change will change the I am also planning to move the Perhaps adding a new catagory, As for how to handle the collisions, its possible to nest, with something like: [icons.ui.bufferline]
separator = "+"
[icons.ui.statusline]
separator = "<"The whitespace icons would be like: [icons.ui.whitespace]
space = "·"
newline = "⏎"For workspace, a top level key would work, in case this icon is used in more than just the current statusline: [icons.ui]
workspace = "W"Its more nesting than I had hoped for, two levels deep here, but this does solve name collisions. Also havent managed to come up with a better way to categorize these kinds of icons. |
|
Added the mentioned structure to give it a try. Also implemented the bufferline separator functionality in #11704 
|
yep its working
|
|
Looking more closely at the bufferline separator, I have removed it, as there are issues to be worked out with it, so will leave that to further develop in that other PR. Its also possible that instead of a separator using (and adding functionality for) a close icon could visually function the same, while also getting added use out of: Instead, to keep the dogfooding going, I have moved Also moved the statusline I actually feel this fits a lot better in the new Also have began to move the remaining "icons" over to the new source. Am trying out a With these changes, you can now have: [icons.ui.virtual]
space = "-"
ruler = "|"
wrap = "↪"
indentation = "|"To note on the ruler and the changes wanted in #11798, I am leaving the ruler as it is now (as a "space"), with the changes needed being to just change over to the new "icon" and then change the ruler themes from a bg to fg. That can be left to a separate PR. #[inline]
pub fn ruler(&self) -> &str {
// TODO: Default: U+00A6: ¦
self.ruler.as_deref().unwrap_or(" ")
}These are a breaking change. Also not sure what other areas might have any non ascii text left? Or maybe this should be all for this PR and then any more could come in subsequent PRs. |
|
RoloEdits
changed the title
|
Tried to update the main description again, though i'm sure ill be adding things to it as I feel the need for clarification. Mainly the review points section, as I come across potential talking points. This PR is now ready for implementation feedback. |
|
The new update works fine for me, but sucks that I can't get to use the buffer line separator :/ |
|
No changes to functionality, just fixing tests.
Yeah, but there are some questions around the direction and how to handle the centering/colors, and I didnt want that to hang this PR up. The other integrated implementations were pretty straight forward or very simple to decide on a final. If its really something you want I would encourage to go to the PR and provide some feedback, that way if this is merged, it might be as simple as picking what icon to use, which would hopefully merge shortly after. |
|
An example of adding an icon to the inline blame from #13133, mimicking Zeds. 
|
that would require #13133 to be merged right? |
Correct |
|
Added some new icons and associations, like |
|
you can see mini.icons neovim pluginn for more references |
|
With the changes from #13776, its a bit unclear how I can always style the icons color. 
Above shows the icons color getting overridden with the Not really sure how to handle this. |
|
@RoloEdits Im currently using your branch on this daily. Is it dead now? |
|
No, I need to rebase it (and my other prs). I will do that today. As far as progress, ive reached a point of needing feedback before I can make progress. There is also the icon themeing issue stated above that has no solution currently. I edited my theme to just not have a fg color on the ui selection. One specific thing is the design around the current folder/directory handling, like how to handle open folders in a tree, for example. And of course the default icons, though this can be done in follow-ups. |
12 participants
Adds a centralized container for icons/symbols that is easy to propagate around to areas that use them. It tries to categorize around both a domain and UI element. UI elements are scoped to parts of the UI, like the statusline and bufferline, to avoid naming collisions and provide clear language to access an icon. Domains encompass something that can be used in multiple places and aren't attached to any specific UI element, like symbols for a struct or variable that can be used in the completion list, breadcrumb, and symbol pickers.
The main goal of this PR is to centralize and provide an API for a way to expose icon customization, rather than having a bunch of ad-hoc ways. It differs from #2869 in that it doesn't use any loader interface. It just uses plain values in a config, with defaults assigned in the source. Also breaking from standard config usage is that it is not attached to the
Editorbut instead a static container ofIcons. This makes propagating the icons very, very easy, and doesn't need any viral changes needed when passing anEditorplaces. This will hopefully make maintaining this low priority item, which the core maintainers might not themselves use or need, much nicer.Despite the unique way of handling the
icons, it still supports refresh on reload. Any patched font usage needs to be manually enabled in the config. Out of box should be similar (though perhaps new choices in icons/symbols) to now.helixitself uses symbols already, and they are moved to the new interface. This has the benefit of now having a uniform way to change things, rather than having aseparatorhere and anindicatorthere.[editor]can now define behavior while[icons]will define look.Icons are added to all pickers, the statusline, bufferline, and the completion list.
Here is an example config:
The goal, though, is to provide a satisfactory default experience inline with a neovim distro, continuing helix's excellent out of box experience.
Examples
Review Points
While the type for some of the symbols might say
String, its an alias added at the top of the file so thatSmartString<LazyCompact>doesnt need to be written everywhere.The icons for filetypes and their colors might take some extra effort to go over. There are many added currently, though unknown how many will want to be added initially. There could be color conflicts with some themes. I think this can only wait till its used in the wild to refine over time. This also adds functionality from other PRs, some done by myself, and others copied over. Im unsure if any will be stripped out so havent added any co-authors, so not sure how we can coordinate credit where its due. We can talk about that more when we get closer to the end.
One minor pain point, where im not sure if there is a better way to handle, is that when a file is listed in a picker, if there is no extension, like say
Makefile, it will show the fallback text, as there is no match found with the info available, in this case just the name. If you open the file it would work as expected in areas where there is more information about aDocument, like the bufferline and statusline:There are some tests in the rustdocs in
icons.rsbut for now areno_runas not sure how to decide what configuration.defaults to load for unit tests, as by default the icons are disabled. Not sure how if there is an existing way to accomplish this or will have to hack something together.Markdown documentation will be added once the final form has settled, or looks like its rounding into form.
Future
Icon Plugins
Another use could come in the form of icon plugins. By providing a single interface to alter icons, which are propagated in the most common areas, a plugin would just need to reassign to new values after the defaults are loaded. If a new icon is needed somewhere, it can be propagated easily.
Ruler Changes
This PR changes so that one can choose a new ruler symbol, but given that the practice right now is to set the BG color, rather than FG, a separate PR can change to a new default and also alter the themes necessary . One major issue around this is if people still want to have the current "space" character and have themes support that. I would image that there would be a check for a space in the code and then special case to clear the FG and set the BG with the themes FG, but that can be left to figure out.
Breaking changes
The following elements have been moved from there current location to the new one:
[editor.statusline.separator]->[icons.ui.statusline.separator][editor.whitespace.characters]->[icons.ui.virtual.*][editor.indent-guides.character]->[icons.ui.virtual.indent][editor.soft-wrap.wrap-indicator]->[icons.ui.virtual.wrap]Supersedes:
Consumes:
vcs:prefix toversion-controlstatusline element #6646Closes:
Related: