Add (customizable) vcs: prefix to version-control statusline element

[kareigu]

Adds config.toml option editor.statusline.version-control-icon, to allow adding a user-defined icon as a prefix to the branch name. Or any other string prefix if wanted.

Also applies any styling defined under the key ui.statusline.versioncontrol.

Example from the kanagawa theme that's been updated to use this new style option, with a Nerd Fonts branch icon.

With background colour in the default theme.

As an additional fix, if the HEAD name is empty, the version-control element won't get drawn.

[lazytanuki]

Hi! FYI this overlaps with #2869 which implements this in a more generic way, that allows to style this particular element's icon.

[pascalkuthe]

I do something similar in my local config by abusing the separator element but that doesn't work as well because you can't use other the separator elsewhere and the symbol is shown even if there is no VCS repo.

However, I am not sure if we want to keep adding a bunch of config options to each statusline element (what about a glyph after the version control element separator, what about status-line element foo, ...). Maybe just adding a generic { glyph = ".." } statusline element that allows insertings arbitrary text as a status line element could be a more sustainable option?

[kareigu]

However, I am not sure if we want to keep adding a bunch of config options to each statusline element (what about a glyph after the version control element separator, what about status-line element foo, ...). Maybe just adding a generic { glyph = ".." } statusline element that allows insertings arbitrary text as a status line element could be a more sustainable option?

I had a similar kind of thought of doing it as a theming option instead by having a glyph field like that or something similar.

Having a separate statusline element for adding icons would bring added annoyance when you want to have a background colour on the element you're styling. As an example the second picture in this PR, achieving that with a separate element would require that specific instance of the glyph element to be stylable and going to your theme to manually have it use the same colours as your version-control element.

[pascalkuthe]

However, I am not sure if we want to keep adding a bunch of config options to each statusline element (what about a glyph after the version control element separator, what about status-line element foo, ...). Maybe just adding a generic { glyph = ".." } statusline element that allows insertings arbitrary text as a status line element could be a more sustainable option?

I had a similar kind of thought of doing it as a theming option instead by having a glyph field like that or something similar.

Having a separate statusline element for adding icons would bring added annoyance when you want to have a background color on the element you're styling. As an example the second picture in this PR, achieving that with a separate element would require that specific instance of the glyph element to be stylable and going to your theme to manually have it use the same colors as your version-control element.

We generally don't allow theming status-line elements individually currently. The only exception is the mode indicator but that is a special case as the color actually communicates additional information here (and is not just eye candy). I think the theming concern probably needs to be addressed separately and consistently across all components so that should be a separate PR and dropped here IMO. So for the time being adding a spacer element should work well and the spaces should be removed.

On second thought adding an option for arbitrary text that prefixes the vcs status seems like a good thing to have though. It lets you know know what that text refers to on the statusline (and avoids the indicator doesn't stick around when there is no branch). This is consistent with other indicators (diagnostics, selection). This isn't necessarily about icons the prefix could also be git=, vcs=, vcs or git for example. I think it should just be a simple `write("{prefix}{branch_name}") tough. As my examples showed the space is easy enough to include in the configuration so by making the space part of the configuration the result is strictly more generic/powerful. It also avoids the need for a condition in the code (you always draw the prefix if the prefix is an empty string it just doesn't change anything). The example you showed would just be " " so this is strictly more flexible.

My idea for arbitrary static status line text are probably better discussed separately and it's not entirely clear if we even want to add them right now. In general, it's sort of hard to draw a line with regard to statusline customization. The TOML config is a stopgap solution until we get a scripting language-based config. This would allow arbitrarily complex statusline customization. Until then we probably shouldn't make the statusline too generic/complex.

[pascalkuthe]

this is what implementing my comments would look like (ofcourse documentation and other code would need to be adjusted)

[univerz]

this is what implementing my comments would look like (ofcourse documentation and other code would need to be adjusted)

is this really the preferred solution how to get icons into all places in helix, compared to #2869? i really do not understand the push against it.

[kareigu]

We generally don't allow theming status-line elements individually currently. The only exception is the mode indicator but that is a special case as the color actually communicates additional information here (and is not just eye candy). I think the theming concern probably needs to be addressed separately and consistently across all components so that should be a separate PR and dropped here IMO. So for the time being adding a spacer element should work well and the spaces should be removed.

Sure, I think having colours on the version-control element could have some other purpose besides just eye candy, like having it change colour based on if your repo state is dirty or if you're behind/ahead origin etc. But as you said, it would need to be a completely different PR altogether.

On second thought adding an option for arbitrary text that prefixes the vcs status seems like a good thing to have though. It lets you know know what that text refers to on the statusline (and avoids the indicator doesn't stick around when there is no branch). This is consistent with other indicators (diagnostics, selection). This isn't necessarily about icons the prefix could also be git=, vcs=, vcs or git for example. I think it should just be a simple `write("{prefix}{branch_name}") tough. As my examples showed the space is easy enough to include in the configuration so by making the space part of the configuration the result is strictly more generic/powerful. It also avoids the need for a condition in the code (you always draw the prefix if the prefix is an empty string it just doesn't change anything). The example you showed would just be " " so this is strictly more flexible.

Yes, that's the primary reason I decided to do this originally, since having a ton of text on the statusline without any extra indicator for what it's related to, could be really confusing to look at. Without the theming aspect your suggested way is also fine, since the padding is only an issue when you set a different background colour from the statusline.

My idea for arbitrary static status line text are probably better discussed separately and it's not entirely clear if we even want to add them right now. In general, it's sort of hard to draw a line with regard to statusline customization. The TOML config is a stopgap solution until we get a scripting language-based config. This would allow arbitrarily complex statusline customization. Until then we probably shouldn't make the statusline too generic/complex.

Totally agree, I don't think arbitrary text elements on the status line will have much use before there's a more moldable way to configure the statusline than just having an array in a TOML file.

[kareigu]

Removed theming functionality and implemented the suggested changes.
Now it's only {prefix}{head} along with the fix to not draw the element when there's no branch information.

Diff might be a bit messy since I rebased to master as well.

[pascalkuthe]

This looks great now 👍 Thanks for sticking with me trough my confused rambeling :D

[pascalkuthe]

we might actually want the default to be vcs instead of an empty string. without the prefix I find this statusline element kind of disorienting and vcs fits with the name of the element/i'ts clear what it does. Some people might prefer git or an icon but that doesn't fit with core (we want to support other vcs in the future and patched font icons don't belong in core) but vcs seems like a pretty good default to me:

ofcourse we could just not have a default too but this seems inline with other elements to me

[kareigu]

Would vcs: or branch: suffice?

Without the : it looks kind of disconnected.

[pascalkuthe]

ah yeah the colon is a nice addition. I like vcs: 👍

[David-Else]

Some people might prefer git or an icon but that doesn't fit with core

Please canversion_control_prefix be configurable? (I see no docs on how to set it even though the title says customizable ) I would not want vcs: name of branch, it does not make actual sense, the version control system is git, not the name of the branch. A nice icon would look great, but I understand why that is up to the user to set.

[kareigu]

Please canversion_control_prefix be configurable? (I see no docs on how to set it even though the title says customizable ) I would not want vcs: name of branch, it does not make actual sense, the version control system is git, not the name of the branch. A nice icon would look great, but I understand why that is up to the user to set.

It's configurable in config.toml under editor.statusline.version-control-prefix

[David-Else]

It's configurable in config.toml under editor.statusline.version-control-prefix

Great! Please can you add this to the docs in this PR? https://docs.helix-editor.com/master/configuration.html Cheers.

[pascalkuthe]

Ah yeah right I was so focused on how it should work that I forgot about the docs during review. This should be added to book/configuration.md

[kareigu]

Right, forgot about that completely. Docs are now updated

[univerz]

last try - i honestly believe that implementation of icons by overwriting dozens of (often duplicate) things named as version_control_prefix compared to icons (maybe even #6796 symbols) API is a bad idea, hard to fix later, and icons could be yet another helix feature done right compared to other editors.

[Shatur]

implementation of icons by overwriting dozens of (often duplicate) things named as version_control_prefix compared to icons (maybe even #6796 symbols) API is a bad idea, hard to fix later, and icons could be yet another helix feature done right compared to other editors

Agree. Having icons configuration in one place is way more convenient. Something more general like #2869 would be better.

[kareigu]

Rebased to master since there were some conflicts due to other docs changes.

Is this something that is still wanted or should we close this and have the behaviour be achievable through the plugin system once it's ready?