[vim/vim] 9.2.0224 regression: newlines in some channel responses (?) are garbled (Issue #20041)

D. Ben Knoble

unread,

Apr 22, 2026, 8:23:11 PM (2 days ago) Apr 22

to vim/vim, Subscribed

benknoble created an issue (vim/vim#20041)

Steps to reproduce

Install vim-fugitive from tpope
Build Vim with and without 9e55474 (patch 9.2.0224: channel: 2 issues with out/err callbacks, 2026-03-22).
Observer that without the patch, :Git status correctly shows multiline outputs. With the patch, :Git status outputs all run together in a single line.

Expected behaviour

The newlines and other structure should be preserved.

Version of Vim

I observe this on 9.2.0389 but also many earlier versions (see later)

Environment

OS: Gentoo GNU/Linux
Terminal: Alacritty (TERM=tmux-256color)
Shell: Zsh 5.9

Logs and stack traces

Here's a `git bisect log`:


# bad: [4c287947164fe26a6bd32e1c9362668388ae7457] patch 9.2.0350: Enabling modelines poses a risk
# good: [e7e21018fc0b60c153c8e668f696d95e574cc5a4] patch 9.2.0: Need a new Vim release
git bisect start v9.2.0350 v9.2.0
# good: [42c6686c78d39843f71dba989a8ea59bc6975132] patch 9.2.0174: diff: inline word-diffs can be fragmented
git bisect good 42c6686c78d39843f71dba989a8ea59bc6975132
# bad: [84a8ee4353142f0eb9b66f70773cad886f5b97a8] runtime(context): use fnameescape() for the Log command
git bisect bad 84a8ee4353142f0eb9b66f70773cad886f5b97a8
# good: [e2f4e18437074868d89ed5c368af8c55ddc394e1] patch 9.2.0223: Option handling for key:value suboptions is limited
git bisect good e2f4e18437074868d89ed5c368af8c55ddc394e1
# bad: [418400075ac94eb4d1caaad1cd5251d994bf2a91] patch 9.2.0246: memory leak in globpath()
git bisect bad 418400075ac94eb4d1caaad1cd5251d994bf2a91
# bad: [8c116bbe79eab7337bb5c979468d3b0cb5933d07] patch 9.2.0235: filetype: wks files are not recognized.
git bisect bad 8c116bbe79eab7337bb5c979468d3b0cb5933d07
# bad: [243dcd1bcb46f5051746d461c00e128e439a4df2] translation(it): Update Italian xxd man page
git bisect bad 243dcd1bcb46f5051746d461c00e128e439a4df2
# bad: [e147b635fc0bb130ab3a094dc7f287674ff1f43f] patch 9.2.0225: runtime(compiler): No compiler plugin for just
git bisect bad e147b635fc0bb130ab3a094dc7f287674ff1f43f
# bad: [9e5547484956e3e8016ab8447170d63ad58d7568] patch 9.2.0224: channel: 2 issues with out/err callbacks
git bisect bad 9e5547484956e3e8016ab8447170d63ad58d7568
# good: [de10c87bed5a79ed80f1bb428a391faefdff13c9] translation: Regenerate desktop files in runtime directory
git bisect good de10c87bed5a79ed80f1bb428a391faefdff13c9
# first bad commit: [9e5547484956e3e8016ab8447170d63ad58d7568] patch 9.2.0224: channel: 2 issues with out/err callbacks


where each step consists of


make -j
VIMRUNTIME=runtime ./src/vim
:Git status
[observe multi-line or not]
:qa!
git bisect [good|bad]


cc @h-east

(I'll leave out most of my commentary for now, but this kind of bug is part of why folks are concerned about LLM-generated code being merged, and I don't see much in the way of review of this code in https://github.com/vim/vim/pull/19776 or companion issue https://github.com/vim/vim/issues/16354.)

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

Apr 22, 2026, 8:24:45 PM (2 days ago) Apr 22

to vim/vim, Subscribed

benknoble left a comment (vim/vim#20041)

(Apologies if this is a duplicate ping:) I had to edit the original post to correct formatting—the bug template doesn't leave any room for additional markdown, assuming anything in "logs" is just going to get shoved into a code block. I'm not sure if, after edits, the "@h-east" will actually notify anyone. So, duplicate that ping.

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

Apr 22, 2026, 8:30:32 PM (2 days ago) Apr 22

to vim/vim, Subscribed

benknoble left a comment (vim/vim#20041)

For better and worse, reverting the commit even from as far forward as d0b6ee3 (patch 9.2.0382: Wayland: focus-stealing is non-working, 2026-04-20) is fairly trivial with git revert (aside the conflict in src/version.c; see this gist with the patch). Presumably that reintroduces the other issue, but it does resolve my bug.

:/

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

Apr 22, 2026, 9:00:52 PM (2 days ago) Apr 22

to vim/vim, Subscribed

benknoble left a comment (vim/vim#20041)

Taking just :Git status as an example, we end up with

jobopts = {'close_cb': function('<SNR>202_RunClose'),
 'env': {'COLUMNS': '255', 'FUGITIVE': '/tmp/vPQTmRA/5', 'GIT_EDITOR': 'sh /tmp/vPQTmRA/4.sh', 'GIT_MERGE_AUTOEDIT': '1', 'GIT_PAGER': 'cat', 'GIT_SEQUENCE_EDITOR': 'sh /tmp/vPQTmRA/4.sh', 'MANPAGER': 'col -b', 'NO_COLOR': '1', 'PAGER': 'cat'},
 'err_cb': function('<SNR>202_RunReceive'),
 'exit_cb': function('<SNR>202_RunExit'),
 'mode': 'raw',
 'out_cb': function('<SNR>202_RunReceive')
 'pty': 1}

argv = ['git',
 '-c',
 'color.advice=false',
 '-c',
 'color.branch=false',
 '-c',
 'color.diff=false',
 '-c',
 'color.grep=false',
 '-c',
 'color.interactive=false',
 '-c',
 'color.pager=false',
 '-c',
 'color.push=false',
 '-c',
 'color.remote=false',
 '-c',
 'color.showBranch=false',
 '-c',
 'color.status=false',
 '-c',
 'color.transport=false',
 '-c',
 'color.ui=false',
 '--no-literal-pathspecs',
 '-c',
 'advice.waitingForEditor=false',
 'status']

before calling job_start(argv, job_opts). By the time we get to RunClose in a working version, it's a:state.file contains the expected output, which is also in a:tmp.echo. RunReceive gets strings of data with correctly embedded newlines. Trimmed example (a single invocation):

'Fichiers non suivis:\r\n  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)\r\n…'

In the non-working version, RunReceive gets things like

(one invocation:) 'Fichiers non suivis'
(next:) '  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)'

It's chopped and the newlines are gone.

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

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

Char

unread,

Apr 23, 2026, 2:42:11 AM (yesterday) Apr 23

to vim/vim, Subscribed

char101 left a comment (vim/vim#20041)

Does it work if you disable pty using this option? In Windows this does not happen because it does not use a pty to run git.

let g:fugitive_pty_debug_override = 0

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

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

mattn

unread,

Apr 23, 2026, 3:41:58 AM (yesterday) Apr 23

to vim/vim, Subscribed

mattn left a comment (vim/vim#20041)

I think the regression comes from the PTY-specific RAW callback splitting added in patch 9.2.0224.

term_start() callbacks in RAW mode used to receive raw chunks, including embedded \r\n. Splitting PTY callback data on newlines changes that behavior and breaks clients like fugitive.

This smaller change keeps the stderr terminal-display fix and the stderr-before-stdout ordering fix, but drops the RAW callback splitting:

diff --git a/src/channel.c b/src/channel.c
index dc8645b060..a0b7b953e2 100644
--- a/src/channel.c
+++ b/src/channel.c
@@ -3510,46 +3510,7 @@ may_invoke_callback(channel_T *channel, ch_part_T part)
 		// invoke the channel callback
 		ch_log(channel, "Invoking channel callback %s",
 						    (char *)callback->cb_name);
-#ifdef FEAT_TERMINAL
-		// For a terminal job in RAW mode (term_start()), split msg on
-		// NL and invoke the callback once per line with trailing CR
-		// stripped.  This ensures out_cb/err_cb receive one line at a
-		// time regardless of how much data arrives in a single read.
-		if (ch_mode == CH_MODE_RAW && msg != NULL
-			&& channel->ch_job != NULL
-			&& channel->ch_job->jv_tty_out != NULL)
-		{
-		    char_u *cp = msg;
-		    char_u *nl;
-
-		    while ((nl = vim_strchr(cp, NL)) != NULL)
-		    {
-			long_u len = (long_u)(nl - cp);
-
-			if (len > 0 && cp[len - 1] == CAR)
-			    --len;
-			argv[1].vval.v_string = vim_strnsave(cp, len);
-			if (argv[1].vval.v_string != NULL)
-			    invoke_callback(channel, callback, argv);
-			vim_free(argv[1].vval.v_string);
-			cp = nl + 1;
-		    }
-		    if (*cp != NUL)
-		    {
-			long_u len = STRLEN(cp);
-
-			if (len > 0 && cp[len - 1] == CAR)
-			    --len;
-			argv[1].vval.v_string = vim_strnsave(cp, len);
-			if (argv[1].vval.v_string != NULL)
-			    invoke_callback(channel, callback, argv);
-			vim_free(argv[1].vval.v_string);
-		    }
-		    argv[1].vval.v_string = msg;
-		}
-		else
-#endif
-		    invoke_callback(channel, callback, argv);
+		invoke_callback(channel, callback, argv);
 	    }
 	}
     }

Disabling fugitive's PTY path also avoids the issue here, which is consistent with this.

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

Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.

h_east

unread,

Apr 23, 2026, 7:14:40 AM (yesterday) Apr 23

to vim/vim, Subscribed

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

@benknoble
Thanks for the thorough bisect and repro.
To clarify on the LLM-generated code: I personally reviewed both the specs and implementation for #19776.
LLM assistance never implies a lack of scrutiny before merging, which you can see in the PR #19892 discussions (related to #16354).

I will follow up later on the proposed fix for this regression suggested by @mattn.
However, applying it directly would likely cause #16354 to reappear, so I think some time is needed to sort it out.

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Apr 23, 2026, 12:10:59 PM (yesterday) Apr 23

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20041)

@benknoble from my side I can also say that I do review all PRs that are sent here, but often times I just don't have anything useful to contribute (or I miss the obvious things, who knows). So it is not like code here get's blindly merged.

For core maintainers, that have shown dedication and contributed over a long time, I trust even more that they use their tools wisely and look into new issues (as it is happening here as well). And I trust those people more than a random drive-by contributor (which doesn't mean that such contributions are not welcome, I am just a bit more careful there).

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

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

D. Ben Knoble

unread,

Apr 23, 2026, 12:24:43 PM (yesterday) Apr 23

to vim/vim, Subscribed

benknoble left a comment (vim/vim#20041)

Yep. To be clear, I'm not saying "ew bad" or "somebody misbehaved" or anything. Just trying to convey why some might be concerned.

I appreciate y'all's work, and I hope my past messages will evidence the kind of tone and balance I wish to convey here.

I'll try the fix out later today.

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

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

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

Reply all

Reply to author

Forward