[vim/vim] [New Feature] Multi line statusline (simple specification) (PR #19123)

h_east

unread,

Jan 7, 2026, 8:51:44 AMJan 7

to vim/vim, Subscribed

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)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

h_east

unread,

Jan 7, 2026, 9:44:59 AMJan 7

to vim/vim, Push

@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

unread,

Jan 7, 2026, 2:16:18 PMJan 7

to vim/vim, Subscribed

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

unread,

Jan 8, 2026, 1:03:03 AMJan 8

to vim/vim, Subscribed

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

unread,

Jan 14, 2026, 12:57:14 AMJan 14

to vim/vim, Subscribed

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

unread,

Jan 14, 2026, 3:33:24 AMJan 14

to vim/vim, Subscribed

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

unread,

Jan 14, 2026, 8:20:29 AMJan 14

to vim/vim, Push

@h-east pushed 1 commit.

72b571f Multi line statusline (simple specification)

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Jan 14, 2026, 9:26:00 AMJan 14

to vim/vim, Subscribed

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

unread,

Jan 14, 2026, 9:52:08 AMJan 14

to vim/vim, Subscribed

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

unread,

Jan 14, 2026, 11:40:35 AMJan 14

to vim/vim, Subscribed

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

unread,

Jan 15, 2026, 7:48:36 AMJan 15

to vim/vim, Subscribed

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

unread,

Jan 18, 2026, 4:28:01 PMJan 18

to vim/vim, Subscribed

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

unread,

Jan 18, 2026, 5:28:02 PMJan 18

to vim/vim, Subscribed

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

unread,

Jan 19, 2026, 8:02:11 AMJan 19

to vim/vim, Subscribed

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

unread,

Jan 19, 2026, 9:46:46 AMJan 19

to vim/vim, Subscribed

@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

unread,

Jan 24, 2026, 6:18:32 AMJan 24

to vim/vim, Push

@h-east pushed 2 commits.

d8cea0f Refactor tabpanel.c (Change line break \n to %@)
32704e9 Add support "\n" for 'tabpanel' for temporarily backward compatibility

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Jan 24, 2026, 6:59:19 AMJan 24

to vim/vim, Push

@h-east pushed 1 commit.

3965593 Fix preproc indent

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Jan 24, 2026, 7:05:10 AMJan 24

to vim/vim, Push

@h-east pushed 1 commit.

c0607e9 fix by CI review

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Jan 24, 2026, 9:41:06 AMJan 24

to vim/vim, Push

@h-east pushed 1 commit.

3405e7d Update 'tabpanel' documentation.

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Jan 24, 2026, 9:59:46 AMJan 24

to vim/vim, Subscribed

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

unread,

Jan 28, 2026, 5:27:45 PMJan 28

to vim/vim, Subscribed

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

unread,

Jan 28, 2026, 6:15:38 PMJan 28

to vim/vim, Subscribed

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

unread,

Jan 29, 2026, 7:06:42 AMJan 29

to vim/vim, Push

@h-east pushed 1 commit.

da0eb5c Merge branch 'master' into multi-line-stl-simple-spec

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Jan 29, 2026, 7:33:34 AMJan 29

to vim/vim, Subscribed

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

unread,

Jan 29, 2026, 8:09:07 AMJan 29

to vim/vim, Subscribed

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

unread,

Jan 29, 2026, 8:11:11 AMJan 29

to vim/vim, Subscribed

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

unread,

Jan 29, 2026, 8:25:43 AMJan 29

to vim/vim, Subscribed

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

unread,

Jan 29, 2026, 8:58:37 AMJan 29

to vim/vim, Subscribed

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

unread,

Feb 2, 2026, 9:10:46 AMFeb 2

to vim/vim, Push

@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.

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 3, 2026, 10:40:36 AMFeb 3

to vim/vim, Push

@h-east pushed 1 commit.

c69845c Fix code by review

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 3, 2026, 10:40:55 AMFeb 3

to vim/vim, Push

h_east

unread,

Feb 5, 2026, 8:28:33 AMFeb 5

to vim/vim, Push

@h-east pushed 9 commits.

236a08a Multi line statusline (simple specification)
43bf83d Refactor tabpanel.c (Change line break \n to %@)
87b629a Add support "\n" for 'tabpanel' for temporarily backward compatibility
7799f2d Fix preproc indent
de87a6a fix by CI review
012d259 Update 'tabpanel' documentation.
22570f5 Fix code by review
309362c Converting tests to :def function
bd830f1 Add test

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 5, 2026, 3:08:35 PMFeb 5

to vim/vim, Push

@h-east pushed 9 commits.

675c404 Multi line statusline (simple specification)
bf0d211 Refactor tabpanel.c (Change line break \n to %@)
b491c83 Add support "\n" for 'tabpanel' for temporarily backward compatibility
8d125d7 Fix preproc indent
a309bb4 fix by CI review
62c2c06 Update 'tabpanel' documentation.
45b66ed Fix code by review
7a63632 Converting tests to :def function
f316634 Refactor test

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 6, 2026, 10:48:47 AMFeb 6

to vim/vim, Push

@h-east pushed 1 commit.

2cb7fee Add "%@" to 'tabpanel' test

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 6, 2026, 11:46:30 AMFeb 6

to vim/vim, Push

@h-east pushed 1 commit.

b899ccb Refactor tabpanel test name

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 11, 2026, 12:03:17 PMFeb 11

to vim/vim, Push

@h-east pushed 12 commits.

513c03c Multi line statusline (simple specification)
945bb1e Refactor tabpanel.c (Change line break \n to %@)
f4d37d3 Add support "\n" for 'tabpanel' for temporarily backward compatibility
8e19af8 Fix preproc indent
1f82d52 fix by CI review
1ae1bec Update 'tabpanel' documentation.
325929b Fix code by review
0a6ed6f Converting tests to :def function
8a36f12 Refactor test
584abc1 Add "%@" to 'tabpanel' test
aa55407 Refactor tabpanel test name
9f771ee Tweak code comment

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 12, 2026, 7:05:50 AMFeb 12

to vim/vim, Push

@h-east pushed 1 commit.

dbf68a8 Fix highlight ('%#', '%*' ) issue

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 12, 2026, 7:56:06 AMFeb 12

to vim/vim, Push

@h-east pushed 1 commit.

a0bf04d fix CI error?

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 12, 2026, 8:13:09 AMFeb 12

to vim/vim, Push

@h-east pushed 1 commit.

73d7089 Fix highlight ('%#', '%*' ) issue

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 12, 2026, 8:27:12 AMFeb 12

to vim/vim, Push

@h-east pushed 1 commit.

3d6ee84 Fix highlight ('%#', '%*' ) issue

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 12, 2026, 10:01:30 AMFeb 12

to vim/vim, Push

@h-east pushed 1 commit.

135a525 Fix by review

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 13, 2026, 3:45:37 AMFeb 13

to vim/vim, Push

@h-east pushed 2 commits.

227c591 Fix around ENABLE_STL_MODE_MULTI_NL
428955c Fix document

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 17, 2026, 10:31:33 AMFeb 17

to vim/vim, Push

@h-east pushed 17 commits.

779448e Multi line statusline (simple specification)
d466429 Refactor tabpanel.c (Change line break \n to %@)
2d13fe4 Add support "\n" for 'tabpanel' for temporarily backward compatibility
e436d18 Fix preproc indent
813d8f2 fix by CI review
c16a462 Update 'tabpanel' documentation.
92e6868 Fix code by review
afdeebd Converting tests to :def function
a584934 Refactor test
1b919d6 Add "%@" to 'tabpanel' test
ead43dc Refactor tabpanel test name
a01d834 Tweak code comment
e3d446c Fix highlight ('%#', '%*' ) issue
61e19e0 Fix by review
fafd38a Fix around ENABLE_STL_MODE_MULTI_NL
5f51c16 Fix document
42e881e tweak test code

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 17, 2026, 12:19:12 PMFeb 17

to vim/vim, Push

@h-east pushed 1 commit.

c0d4e88 Refactor

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 20, 2026, 11:42:10 PMFeb 20

to vim/vim, Push

@h-east pushed 4 commits.

280c834 Multi line statusline (simple specification)
2958974 Refactor tabpanel.c (Change line break \n to %@)
5ccb6ca Add support "\n" for 'tabpanel' for temporarily backward compatibility
9834a44 Refactor

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

h_east

unread,

Feb 26, 2026, 7:49:28 PM (12 days ago) Feb 26

to vim/vim, Push

@h-east pushed 4 commits.

329c083 Multi line statusline (simple specification)
804cfe7 Refactor tabpanel.c (Change line break \n to %@)
ae6b1ba Add support "\n" for 'tabpanel' for temporarily backward compatibility
1e3237a Refactor

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Copilot

unread,

Feb 28, 2026, 12:50:08 PM (10 days ago) Feb 28

to vim/vim, Subscribed

@Copilot commented on this pull request.

Pull request overview

This PR incrementally introduces a simpler multi-line statusline specification for Vim by adding a new global 'statuslineopt' option (currently supporting maxheight:) and enabling a line-break token in statusline-like format strings.

Changes:

Add global 'statuslineopt' (maxheight:{n}) and wire it into window layout/statusline height calculations.
Extend statusline-format parsing/rendering to support a line-break item (%@) and update tabpanel rendering to use the multi-line statusline builder.
Add/adjust tests, screendumps, and documentation for the new option/format behavior.

Reviewed changes

Copilot reviewed 25 out of 33 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/window.c	Introduces statusline height helpers and propagates multi-line status height through split/equalize/layout logic.
src/vim.h	Adds statusline rendering mode enum and temporary compatibility macro.
src/vim.h	Adds statusline rendering mode enum and temporary compatibility macro.
src/testdir/util/gen_opt_test.vim	Adds generated option validation cases for `'statuslineopt'`.
src/testdir/test_tabpanel.vim	Updates tabpanel tests to prefer `%@` line breaks and refactors some test names.
src/testdir/test_statuslineopt.vim	Adds new automated tests for multi-line statusline behavior and best-effort maxheight.
src/testdir/dumps/Test_tabpanel_with_tabline_0.dump	New/updated screendump baseline for renamed tabpanel test.
src/testdir/dumps/Test_tabpanel_noeval_0.dump	New screendump baseline for renamed tabpanel test.
src/testdir/dumps/Test_tabpanel_noeval_1.dump	New screendump baseline for renamed tabpanel test.
src/testdir/dumps/Test_tabpanel_eval_0.dump	New screendump baseline for renamed tabpanel test.
src/testdir/dumps/Test_tabpanel_eval_1.dump	New screendump baseline for renamed tabpanel test.
src/testdir/dumps/Test_tabpanel_eval_with_linebreaks_0.dump	Updated screendump reflecting `%@`-based line breaking.
src/testdir/dumps/Test_tabpanel_eval_with_linebreaks_1.dump	New/updated screendump for `%@`/alignment behavior.
src/testdir/dumps/Test_tabpanel_cmdline_compl_0.dump	Adds screendump baseline for cmdline completion with tabpanel.
src/testdir/dumps/Test_tabpanel_cmdline_compl_1.dump	Adds screendump baseline for cmdline completion with tabpanel + pum.
src/testdir/dumps/Test_multistatusline_highlight_01.dump	Adds screendump baseline for multi-line statusline highlight test.
src/testdir/dumps/Test_multistatusline_highlight_02.dump	Adds screendump baseline for multi-line statusline highlight test.
src/testdir/Make_all.mak	Registers the new `test_statuslineopt` in the test runner.
src/tabpanel.c	Refactors tabpanel drawing to use multi-line statusline builder and centralized highlight rendering.
src/structs.h	Updates `w_status_height` documentation to reflect multi-line heights and update timing.
src/screen.c	Updates custom statusline/ruler/tabline drawing to render multiple statusline rows.
src/proto/window.pro	Adds prototypes for new window/statuslineopt helpers.
src/proto/optionstr.pro	Adds prototypes for `'statuslineopt'` option handlers/expansion.
src/proto/buffer.pro	Adds prototypes for multi-line statusline builders and rendered-height helper.
src/optionstr.c	Adds `'statuslineopt'` handlers and updates statusline format validation for `%@`.
src/optiondefs.h	Defines the new `'statuslineopt'` option.
src/option.h	Adds `STL_LINEBREAK` token and declares the new option variable `p_stlo`.
src/gui.c	Updates mouse hit-testing to account for multi-line statusline height.
src/feature.h	Updates feature documentation to include `'statuslineopt'` under +statusline.
src/drawscreen.c	Updates status redraw filling to cover multiple statusline rows.
src/buffer.c	Implements multi-line statusline builder variants and line-break parsing.
runtime/doc/windows.txt	Mentions that statusline height can be changed via `'statuslineopt'`.
runtime/doc/tags	Adds help tags for `'statuslineopt'` and the new `%@` item.
runtime/doc/options.txt	Documents `%@` and the `'statuslineopt'` option; updates tabpanel docs for `%@` usage.
src/vim.h	Adds statusline rendering mode enum and temporary compatibility macro.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

In src/window.c:

> +    stlh_effort = stlo_mh;
+    FOR_ALL_TAB_WINDOWS(tp, wp)
+	frame_change_statusline_height_rec(tp->tp_topframe, false);
+
+    stlo_mh = stlh_effort;
+    FOR_ALL_TAB_WINDOWS(tp, wp)
+	frame_change_statusline_height_rec(tp->tp_topframe, true);

frame_change_statusline_height() iterates with FOR_ALL_TAB_WINDOWS(tp, wp) but then calls frame_change_statusline_height_rec(tp->tp_topframe, ...) for every window. This ends up walking the full frame tree multiple times per tabpage (O(windows^2)) and, in the actual_change pass, repeatedly calls win_new_height() for the same windows. Iterate tabpages once (e.g. FOR_ALL_TABPAGES(tp)) and call the recursive helper once per tp->tp_topframe for each pass.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

h_east

unread,

Mar 1, 2026, 8:23:30 AM (9 days ago) Mar 1

to vim/vim, Push

@h-east pushed 5 commits.

a86c161 Multi line statusline (simple specification)
fdd8522 Refactor tabpanel.c (Change line break \n to %@)
adbc5d4 Add support "\n" for 'tabpanel' for temporarily backward compatibility
19981eb Refactor
a30d791 Fix Copilot suggestions

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

h_east

unread,

Mar 1, 2026, 8:26:06 AM (9 days ago) Mar 1

to vim/vim, Subscribed

@h-east commented on this pull request.

In src/window.c:

> +    stlh_effort = stlo_mh;
+    FOR_ALL_TAB_WINDOWS(tp, wp)
+	frame_change_statusline_height_rec(tp->tp_topframe, false);
+
+    stlo_mh = stlh_effort;
+    FOR_ALL_TAB_WINDOWS(tp, wp)
+	frame_change_statusline_height_rec(tp->tp_topframe, true);

Thanks.
Changed the macro FOR_ALL_TAB_WINDOWS to FOR_ALL_TABPAGES in frame_change_statusline_height().

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

h_east

unread,

Mar 1, 2026, 10:10:05 AM (9 days ago) Mar 1

to vim/vim, Subscribed

h-east left a comment (vim/vim#19123)

It's ready to be merged.
It would be quite difficult to make 'statuslineopt' window-local, so I think it's more realistic to merge it as a global value.

Below are my thoughts.

"Compatibility" as a Misnomer

Calling this a 'compatibility issue' is a misinterpretation of the term.
Compatibility usually refers to maintaining backward compatibility with older
versions of Vim or adhering to established industry standards. Neovim's
independent addition of a feature does not constitute a standard for Vim.
Demanding that Vim's core specifications be restricted by the choices of a
fork project is not about compatibility—it is an attempt to treat Vim as a
sub-project of Neovim, which is fundamentally unacceptable.

Identity and Sovereignty of Vim

Vim has its own evolutionary path and design philosophy. As a maintainer, my
priority is to implement the best possible solution for Vim's users and its
codebase. If %@ is the most intuitive choice for representing line breaks in a
multi-line status line, then that is the 'correct' specification for Vim. We
cannot allow the independent extensions of a fork to dictate or paralyze the
future development of the original project. Maintaining the independence of
Vim's specifications is essential for the health of the ecosystem.

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

You are receiving this because you are subscribed to this thread.

h_east

unread,

Mar 1, 2026, 10:42:59 AM (9 days ago) Mar 1

to vim/vim, Push

@h-east pushed 1 commit.

e2b9361 Refactor

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Mar 1, 2026, 12:01:54 PM (9 days ago) Mar 1

to vim/vim, Subscribed

Closed #19123 via a418631.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Mar 1, 2026, 12:02:08 PM (9 days ago) Mar 1

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#19123)

Thanks 🙏

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

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

Mar 4, 2026, 3:10:40 PM (6 days ago) Mar 4

to vim/vim, Subscribed

benknoble left a comment (vim/vim#19123)

My opinion was not requested, but: I think it is a mistake not to work with the Neovim project where doing so makes sense and is easy. They have generously contributed here and (AFAIK) take almost all changes, esp. on the runtime side, seriously for inclusion on their end.

Yes, there are differences. Minimizing differences in the syntax of an option (for example) helps magnify the differences of import to users on both sides.

It is perfectly OK to discuss multiple kinds of compatibility here, and shutting down attempts to collaborate dooms us more than it helps us. Let’s be good stewards of a shared ecosystem.