[vim/vim] 'stl' and 'stlnc' fillchars not respected when linking StatusLineNC to StatusLine (Issue #13366)

[C.D. MacEachern]

Steps to reproduce

minimal.vim:

filetype plugin indent on
syntax on
set fillchars="stl: ,stlnc: " 
split
" when this is commented out there is no problem
hi! link StatusLineNC StatusLine

vim --clean -u minimal.vim

Notice the '^' character is used, even though we've set both stl and stlnc to be a blank character.

Expected behaviour

Vim should always use the user set fillchars for 'stl' and 'stlnc' if they were set by the user.

Version of Vim

9.0.2040

Environment

macOS
Wezterm nightly
'wezterm'
zsh

Logs and stack traces

No response

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/13366@github.com>

[C.D. MacEachern]

Couldn't find any related issue here, but neovim has a few that might be relevant, such as: neovim/neovim#25267

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/13366/1766642578@github.com>

[Christian Brabandt]

I think this is the default value, that is used when otherwise the statusline would become empty.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/13366/1766713063@github.com>

[C.D. MacEachern]

My guess is that when setting the stl fillchar it checks whether the value is empty, which it is, but doesn't consider that the user might have set that intentionally, and so does as it's supposed to when it's empty and uses the alternate ^.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/13366/1766963609@github.com>

[Christian Brabandt]

It's easy enough to change, but I am not sure we should do this. The following patch would "fix" this behaviour:

diff --git a/src/screen.c b/src/screen.c
index 3d931ab4e..fd69cf0b3 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -4462,16 +4462,7 @@ fillchar_status(int *attr, win_T *wp)
        *attr = HL_ATTR(HLF_SNC);
        fill = wp->w_fill_chars.stlnc;
     }
-    // Use fill when there is highlighting, and highlighting of current
-    // window differs, or the fillchars differ, or this is not the
-    // current window
-    if (*attr != 0 && ((HL_ATTR(HLF_S) != HL_ATTR(HLF_SNC)
-                       || wp != curwin || ONE_WINDOW)
-                   || (wp->w_fill_chars.stl != wp->w_fill_chars.stlnc)))
-       return fill;
-    if (wp == curwin)
-       return '^';
-    return '=';
+    return fill;
 }

Note to myself: If we change it, we also need to adjust the documentation at :h fillchars which mentions this briefly, although it may not be completely clear to everybody when reading this:

          Any one that is omitted will fall back to the default.  For "stl" and
          "stlnc" the space will be used when there is highlighting, '^' or '='
          otherwise.

Opinions?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/13366/1784161295@github.com>

[C.D. MacEachern]

I'm nowhere near qualified to have an opinion on this. I'll trust whatever you think is best, this is fine to just close if you think it's not worth fixing. Sometimes it's better to stick with the devil you know haha

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/13366/1786220600@github.com>

[tj-moody]

I think this is the default value, that is used when otherwise the statusline would become empty.

The ^^^ actually appears when the StatusLineNC and StatusLine groups are the same. The conditions that the code guards against are okay to bypass. For the *attr != 0 check, this shouldn't actually matter, as in the original code the highlight group used isn't changed, just the text that uses that highlight group. So checking for the highlight itself is unimportant.

As for the remaining checks, I assume that their intent is to differentiate between active and inactive windows if the statusline highlight groups are the same. That is, if it's impossible to differentiate between active/inactive windows by the color of the statusline, then vim forces the user to differentiate by using different characters, ^ and =.

By always using the user-specified fill value, what actually changes is that if the active/inactive statusline colors are the same, vim would now just allow the statuslines to look the same.

It's ultimately a decision more of intent rather than correctness, and I would argue that the revised version is more correct as it doesn't override user customization.

For reference, I authored the neovim PR that was linked, which has been in nightly for a while and hasn't caused problems to my knowledge.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/13366/1790617530@github.com>

[Christian Brabandt]

Closed #13366 as completed via 6a650bf.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/13366/issue_event/10905492139@github.com>