[vim/vim] [New Feature] Multi line statusline (simple specification) (PR #19123)
h_east
I submitted PR #18871 two months ago.
However, because I set out an ideal final specification, I had to resolve several major issues and it nearly stalled.
So I closed that PR and switched to a more realistic approach, gradually merging the specifications one by one.
- Make the 'statuslineopt' option global only.
- Remove the "fixedheight:" option from 'statuslineopt' and make it fixed at all times.
- Make the "maxheight:" option in 'statuslineopt' a best-effort value. (We will strive to keep the value as close to the specified value as possible for all windows on all tab pages.)
This way, I thought it would be feasible to implement without having to worry about things like uniform window heights.
@chrisbra and All,
Is there a chance this will be merged into mainstream?
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/19123
Commit Summary
- 5d0c810 Multi line statusline (simple specification)
File Changes
(20 files)
- M runtime/doc/options.txt (26)
- M runtime/doc/tags (3)
- M runtime/doc/windows.txt (1)
- M src/buffer.c (115)
- M src/drawscreen.c (9)
- M src/feature.h (5)
- M src/gui.c (8)
- M src/option.h (5)
- M src/optiondefs.h (8)
- M src/optionstr.c (51)
- M src/proto/buffer.pro (2)
- M src/proto/optionstr.pro (2)
- M src/proto/window.pro (3)
- M src/screen.c (106)
- M src/structs.h (11)
- M src/testdir/Make_all.mak (2)
- M src/testdir/test_options.vim (5)
- M src/testdir/util/gen_opt_test.vim (1)
- M src/vim.h (10)
- M src/window.c (253)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
@h-east pushed 1 commit.
- 6725132 Multi line statusline (simple specification)
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19123)Thanks, I think this is a nice addition.
Is there a chance this will be merged into mainstream?
Yes after the 9.2 release. We can then work out the remaining issues.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)Under the specification of this PR, the code is almost complete and works as intended.
(I'll add a few tests to test_statuslineopt)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
thinca
thinca left a comment (vim/vim#19123)How about using "\n" as a line break?
'tabpanel' does this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)The tabpanel specification is odd.
I plan to change it to “%@”. Neither the statusline nor the tabpanel should be split using actual newline characters.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)@chrisbra and All,
I don't think it's a good Vim specification for tabpanels to break lines with \n. I think the tabpanel specification change should be made by the 9.2 release, and it will be difficult to do so after that.
So in this PR I've reduced the multi-line statusline to a simpler specification and introduced a line break mechanism with %@ to 'statusline'. Then, to match this, I'm planning to change the specification of 'tabpanel' (abolishing line breaks with \n and introducing line breaks with %@) and refactor tabpanel.c, which is difficult to maintain.
Is the above plan acceptable?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19123)%@ may cause some confusion:
Copilot.png (view on web)
Note that GitHub Copilot's answer is incorrect here, as clickable statusline areas is a Neovim-only feature.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19123)I don't follow. I'd argue using \n would be a reasonable choice as linebreak character, since it is widely known even outside of the Vim community.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)Thank you for your feedback. I understand that \n is widely recognized, but I have concerns about using it for line breaks in 'statusline', 'tabpanel' and 'tabline':
1. Inconsistency with 'statusline' family options design philosophy
The 'statusline' family options are fundamentally built around a %-based item syntax (e.g., %f, %=, %%). Introducing \n as a line break mechanism would break this consistent design pattern. For uniformity, line breaks should also use a %-based syntax like %@.
2. Quote-dependent behavior causes confusion
In Vim script, \n behaves differently depending on the quote type:
-
"\n" (double quotes) → interpreted as actual newline character (0x0A)
-
'\n' (single quotes) → interpreted as literal two-character string \n
This creates confusion when users set 'statusline':
set statusline=Line1\nLine2 " May not work as expected let &statusline="Line1\nLine2" " Becomes actual newline at assignment let &statusline='Line1\nLine2' " Remains literal \n
3. Parsing ambiguity concerns
When \n is converted to an actual newline character (0x0A) before the parser processes it, the parser cannot distinguish between:
-
Intentional line breaks (user’s desired formatting)
-
Unintentional newlines (from external data, user input, or file contents)
For example:
let &stl="abc\ndef"
At this point, \n has already been converted to byte 0x0A. The 'statusline' parser receives: "abc" + <0x0A> + "def" as a byte sequence, with no way to know whether this newline was intentional.
This is a fundamental design flaw—mixing control characters (formatting) with data (display content) at the same byte-level makes the parser fragile and potentially vulnerable.
With a %-based syntax, the parser can explicitly recognize line breaks as formatting directives, separate from data content.
4. Alignment with 'tabpanel'
I believe 'tabpanel' should also use %-based line breaks for consistency. Since 'tabpanel' is still relatively new (merged in patch 9.1.1391 on 2025 May), this is the right time to establish a consistent specification before 9.2 release.
For these technical reasons, I believe a %-based line break mechanism is more appropriate for both 'statusline' and 'tabpanel'.
Would you be open to reconsidering the use of %-based syntax for line breaks?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19123)Okay fair. But changing tabpanel spec after the release is a bit late. Perhaps we should mark it experimental still, so that we can change the designating new-line atom. Also there is the neovim conflict for %@ as pointed out by @zeertzjq Is there a different mark we could use here?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19123)Perhaps %;? A semicolon naturally has the "separator" meaning.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)Thank you for reconsidering.
Why not document the "\n" line break in 'tabpanel' as "deprecated" and remove it in the next release (9.3 or 10.0)?
Also there is the neovim conflict for %@ as pointed out by @zeertzjq Is there a different mark we could use here?
Well, honestly, even now, When you use Neovim's %@FunaName@ ...%@, it should be judged by if has('nvim'). In other words, it should be fine even if Vim uses "%@" for something else in 'statusline'.
Here's my personal opinion...
- Neovim is something else that used to be Vim.
- I appreciate that the Neovimn members are fixing Vim-related bugs, but I don't like the idea of porting almost all of Vim's new features.
"Vim is not a subproject of Neovim."
Maybe the Neovim guys are planning to port this feature too?
If they do, it would be a bit disappointing, but that's a separate discussion.
In any case, I believe Vim should make its own design decisions without being constrained by Neovim's choices.
--
Best regards,
Hirohito Higashi (h_east)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
@zeertzjq commented on this pull request.
In src/option.h:
> @@ -1383,6 +1385,7 @@ enum
#endif
#ifdef FEAT_STL_OPT
, WV_STL
+ , WV_STLO
This is no longer needed as 'statuslineopt' is now a global option.
In src/testdir/test_options.vim:
> + elseif opt == 'statuslineopt' + exe 'setl ' .. opt .. '=maxheight:4' + exe 'setg ' .. opt .. '=maxheight:5,fixedheight'
This code is never executed as 'statuslineopt' is not a window global-local option anymore, and isn't included in the result of GetGlobalLocalWindowOptions().
In src/testdir/test_options.vim:
> + elseif opt == 'statuslineopt'
+ call assert_equal('maxheight:5,fixedheight', eval('&g:' .. opt), 'option:' .. opt)
same here
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
h_east
h_east
h-east left a comment (vim/vim#19123)@chrisbra
I refactor tabpanel.c to Change line break "\n" to "%@".
Add support "\n" for 'tabpanel' for temporarily backward compatibility.
And the documentation now states that "\n" will no longer be supported in future versions.
I have confirmed that the latest commit (3405e7d) of this PR works with g:anypanel_sep = "%@" and "\n" in vim-anypanel (https://github.com/h-east/vim-anypanel).
Let's merge this PR before the 9.2 release!
If you agree, we will make the necessary corrections.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19123)Sorry, that is a bit late now and I am only merging clear bug fixes. I'll just mark using "\n" as experimental and likely to be changed.
I can merge this after 9.2 and I feel like the correct % atom needs a bit more discussion, especially with regard to Neovim. I guess they will likely also merge this? @clason @zeertzjq ?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19123)It seems that this was also discussed in neovim/neovim#12925
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)Sorry, that is a bit late now and I am only merging clear bug fixes. I'll just mark using "\n" as experimental and likely to be changed.
I'm sorry too. I was aware of the situation and made a strong offer. Your judgment is absolutely correct. Thank you.
I can merge this after 9.2
Thanks.
Please wait until I fix the following known issues and add tests:
- If start Vim without any arguments, the intro screen will disappear after 3 seconds due to redrawing.
... and I feel like the correct
%atom needs a bit more discussion, especially with regard to Neovim. I guess they will likely also merge this? @clason @zeertzjq ?
As I have already stated, Neovim is "something that used to be Vim," so I don't think there's any need for us to worry about compatibility.
Furthermore, since the Neovim guys don't seem interested in incorporating the features in this PR, I think the current specification of "%@" is fine.
By the way, the reason why "＠" is used comes from :h <Nul>.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#19123)Sometimes things may happen in the other direction, when a Neovim feature is merged into Vim. I thought about this as well, and couldn't find any request for adding clickable statusline area into Vim, so perhaps this isn't a problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Justin M. Keyes
justinmk left a comment (vim/vim#19123)since the Neovim guys don't seem interested in incorporating the features in this PR, I think the current specification of "%@" is fine.
It's likely that Neovim will merge this feature, since the code is fairly compatible with the existing statusline impl.
Users, and AI, benefit if we don't diverge unnecessarily. If Vim ever adds "click regions" to statusline, choosing some other syntax for that will add 2x confusion for users.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)Please stop talking about "something that was Vim" here.
You're just adding your own features and incorporating Vim's features without permission. Vim shouldn't have to take into consideration the features you've added.
Don't try to justify yourselves with weird theories.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#19123)Neovim guys will be flexible and not hesitate to change the specifications, right?
When this feature is merged into Vim, all problems will be solved by changing the specifications of the feature on the Neovim side.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
@h-east pushed 6 commits.
- f7f66e6 Multi line statusline (simple specification)
- 4916560 Refactor tabpanel.c (Change line break \n to %@)
- 885b563 Add support "\n" for 'tabpanel' for temporarily backward compatibility
- 24c5498 Fix preproc indent
- 31ed73a fix by CI review
- 09dda39 Update 'tabpanel' documentation.
You are receiving this because you are subscribed to this thread.
