[vim/vim] statusline: Restoring a `User{N}` highlight inside an item group causes the whole item group to disappear (Issue #14993)
Antoine Cotten
Steps to reproduce
Inside a statusline, an item group disappears whenever it contains a highlight restore item, i.e. either %* or %0*.
However, the same item group gets rendered if a %N* item is positioned before the item group.
Demonstration
:hi User1 guifg=Red
:hi User2 guifg=Blue
-
Inner segment highlighted with
User1, no other user highlight in the statusline::set statusline=--%(x%1*MyFunc%*x%)--
statusline is rendered without the item group, neither the colored text nor the inner 'x's are printed:
image.png (view on web) -
Item group prefixed with another user highlight (it doesn't matter which one):
:set statusline=--%2*%(x%1*MyFunc%*x%)--
statusline is rendered with the item group, but not with the desired appearance due to workarounds:
image.png (view on web)Here the item group no longer disappears, but having to prefix it with a
User{N}highlight is a hack that results in visual glitches, and possibly other side effects.
Expected behaviour
In the first case above, the statusline should have been rendered with the text "MyFunc" highlighted in red, with all surrounding characters highlighted according to the built-in StatusLine highlight group:
image.png (view on web)
Version of Vim
9.0.1499
Environment
Operating system: Debian 12 inside WSL2
Terminal: wezterm
Shell: zsh 5.9
Logs and stack traces
xref. neovim/neovim#29306
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
This seems to work if a minwid is added to the group item:
:set statusline=--%1(x%1*MyFunc%*x%)--
From the source code, it seems that the special behavior when minwid is omitted is intentional, but it's not clear what the reason for such behavior is.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Antoine Cotten
@zeertzjq correct, this is intentional and documented in the help section for 'statusline'.
It does indeed work, but for my use case it is undesirable. For more context: I want that group to only appear if it contains information (LSP diagnostics), and a minid would defeat that purpose.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Hm, I wonder what the fallout would be if we change this. Does it only happen with custom user highlighting and not with custom highlighting groups?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Antoine Cotten
This seems to happen only with User{N} highlights yes. As far as I understand, based on the Vim help, these highlights are treated differently:
- They can be restored (to
StatusLine) with%*, unlike "named" highlight groups. - The
StatusLineNCbackground color is applied automatically in non active windows.
Both of these properties make it really easy to craft minimal, plugin-less status bars.
My current workaround is to replace the User2 fg=blue in the example above with a fg and bg which match StatusLine exactly. This is how I captured the screenshot under "Expected behavior".
While this hack works, it defeats the purpose of leveraging User {N} highlight groups.
To me the observed behavior isn't the intended one: since the text inside the item group isn't an empty string (ref. 'statusline' help) there is no reason for it to disappear.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
This does happen with custom highlight groups. E.g. using Search:
:set statusline=--%(x%#Search#MyFunc%##%)--
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Antoine Cotten
TIL about %##. Previous comment edited, thanks!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I see thanks. We had previous discussions on the statusline and how sometimes empty sections are hidden when they shouldn't been but this would always be a backwards incompatible change and I am sure someone would complain, if we change the existing behaviour.
I think the best work-around is to use a custom function %{%MyFunc()%} and your function you can test if you want to return anything, then use the minwidth item so it is displayed correctly or return an empty string to hide this section. Would this work for you?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Antoine Cotten
sometimes empty sections are hidden when they shouldn't be but this would always be a backwards incompatible change and I am sure someone would complain
If the behavior is known to be wrong I can't say I agree with the statement, but I respect the decision.
At the very least let's consider fixing the docs.
This thread now contains two workarounds, so I'm closing the issue. Thanks for chiming in!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Antoine Cotten
Closed #14993 as not planned.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.