[vim/vim] cf4d9625c (patch 9.1.1898: tabpanel: inconsistent use of cmdline with tabpanel, 2025-11-06) broke `vim --version` (Issue #19309)

D. Ben Knoble

unread,

Feb 1, 2026, 5:34:06 PM (yesterday) Feb 1

to vim/vim, Subscribed

benknoble created an issue (vim/vim#19309)

The offending code is

https://github.com/vim/vim/blob/cf4d9625c6eb21107e030dc879c1390596fbdb8d/src/version.c#L4661

In particular, command_line_scan() knows to initialize Columns when producing a --version report, and list_features() used to look at Columns. As of the referenced commit, it instead looks at the uninitialized cmdline_width (0 on my machine). Instead of a tabularized report of features, we get a single column listing.

I can think of a few possible fixes:

revert the change to Columns in list_features()
initialize cmdline_width in command_line_scan()
(nuclear option) revert the whole patch, which might have some nasty snowball consequences.

One thing I can't figure out is why the original patch seems to blindly change Columns to cmdline_width everywhere; it's not explained in the commit message or PR, which are nominally about the tabpanel. Anyway, it's clear we can't substitute one for the other in all cases.

cc @h-east

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

D. Ben Knoble

unread,

Feb 1, 2026, 5:44:43 PM (yesterday) Feb 1

to vim/vim, Subscribed

benknoble left a comment (vim/vim#19309)

The following patch helps, but doesn't restore the behavior I know from 9.1.1775:

diff --git i/src/version.c w/src/version.c
index e18b2c8c3..a499f4a0d 100644
--- i/src/version.c
+++ w/src/version.c
@@ -5117,7 +5117,7 @@ list_in_columns(char_u **items, int size, int current)
     }
     width += 1;
 
-    if (cmdline_width < width)
+    if (Columns < width)
     {
 	// Not enough screen columns - show one per line
 	for (i = 0; i < item_count; ++i)
@@ -5131,7 +5131,7 @@ list_in_columns(char_u **items, int size, int current)
 
     // The rightmost column doesn't need a separator.
     // Sacrifice it to fit in one more column if possible.
-    ncol = (cmdline_width + 1) / width;
+    ncol = (Columns + 1) / width;
     nrow = item_count / ncol + ((item_count % ncol) ? 1 : 0);
 
     // "i" counts columns then rows.  "idx" counts rows then columns.

In particular, on that older version, I get 4 columns. With this patch I only get 3.

One thing I can't figure out is why the original patch seems to blindly change Columns to cmdline_width

I suppose I understand now that in the context of the tabpanel, you'd need the version listing to fit inside the shrunken command line space. So perhaps this patch is better, but it's still 3 columns instead of 4.

diff --git i/src/main.c w/src/main.c
index 5ae94e43e..27cfdb0ed 100644
--- i/src/main.c
+++ w/src/main.c
@@ -2182,6 +2182,7 @@ command_line_scan(mparm_T *parmp)
 		else if (STRICMP(argv[0] + argv_idx, "version") == 0)
 		{
 		    Columns = 80;	// need to init Columns
+		    cmdline_width = 80;
 		    info_message = TRUE; // use mch_msg(), not mch_errmsg()
 # if defined(FEAT_GUI) && !defined(ALWAYS_USE_GUI) && !defined(VIMDLL)
 		    gui.starting = FALSE; // not starting GUI, will exit

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

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

D. Ben Knoble

unread,

Feb 1, 2026, 5:59:10 PM (yesterday) Feb 1

to vim/vim, Subscribed

benknoble left a comment (vim/vim#19309)

Ah, the 4 columns to 3 columns is due to 368710a (patch 9.1.1784: Wayland code can be improved, 2025-09-22), which is unrelated; it bumps with width up from 19 to 21, so we only fit 3 columns instead.

I'd probably go with the 2nd patch as a simple bugfix then cc @chrisbra

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

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

h_east

unread,

2:45 AM (17 hours ago) 2:45 AM

to vim/vim, Subscribed

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

I wrote a patch with test. I'll submit a PR.

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

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

Christian Brabandt

unread,

5:23 AM (15 hours ago) 5:23 AM

to vim/vim, Subscribed

Closed #19309 as completed via 65c5b8e.

—
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,

8:23 AM (12 hours ago) 8:23 AM

to vim/vim, Subscribed

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

@benknoble Thanks for reporting and investigating.

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

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

D. Ben Knoble

unread,

8:30 AM (11 hours ago) 8:30 AM

to vim/vim, Subscribed

benknoble left a comment (vim/vim#19309)