#16490 enabled 'termguicolors' from the RGB answer, and 9.1.1114 commented that
out after #16539, #16568 and #16649 - the code this PR revives. Reviving the
query is not the part that went wrong: those three reports were about Vim
switching the option on its own, which this patch no longer does. The interface
it puts in place instead is where the problems are.

v:termrgbresp should hold the raw response

All nine existing v:term* variables hold the escape sequence exactly as the
terminal sent it, and each entry in eval.txt opens with "The escape sequence
returned by the terminal for the |t_XX| request". v:termrgbresp should carry
the DCS response the same way, and its entry should read the same way.

Handing out the capability value instead moves its interpretation into the
vimrc. ncurses allows RGB as a boolean, as a number (bits per channel) or as a
string ("8/8/8"), so v:termrgbresp == '8' from the PR description holds for
the terminals you tested and not necessarily for the next one. Deciding what
counts as direct color support is work Vim should do once, not work every
vimrc repeats.

The negative answer never arrives

The new branch is reached only when code[0] is '1' and code[9] is '='. A
terminal that reports the capability as unsupported (DCS 0 + r ... ST), or that
ignores XTGETTCAP altogether, leaves v:termrgbresp empty and fires no
TermResponseAll. eval.txt states that the variable "is used to find out whether
the terminal supports direct color", but only the positive half is covered: an
autocommand can act on yes, nothing reports no, and a script has no moment at
which it may conclude that the answer is not coming.

terminalprops() already has the right shape for this. It reports 'y', 'n' or
'u' per property, and its entries are filled in from terminal replies, "decrqm"
among them. A direct color entry there, set from both the positive and the
negative XTGETTCAP answer and paired with the TermResponseAll event this PR
adds, would cover no and unknown and would keep the interpretation of the
capability value inside Vim.

The value should be lowercase

term.c, autocmd.c and the test all use "RGB", where every other TermResponseAll
value is lowercase: "ambiguouswidth", "background", "cursorblink",
"cursorshape", "da1", "osc", "version". The pattern of a TermResponseAll
autocommand goes through match_file_pat(), which ignores case only when
'fileignorecase' is set, so au TermResponseAll rgb matches on Windows and
macOS and misses on Unix. "rgb" in all four places, listed between "osc" and
"version" in autocmd.txt, keeps the event usable the same way everywhere.

The disabled code should go, not grow

After the patch, if (val == 8 && !p_tgc_set) guards a ch_log call and an
#if 0 block; without FEAT_EVAL its body is empty. The val computation and
the p_tgc_set test exist only to serve code that no longer runs. If the RGB
answer is no longer used for turning the option on, drop set_option_value along
with the condition around it, rather than adding redraw_asap() to the disabled
branch.

The comment above the key_names table, "Do those ones first, both may cause a
screen redraw", was written when RGB switched 'termguicolors'. It no longer
applies.

Hunks that should come out

runtime/doc/tags and runtime/syntax/vim.vim are not needed in this PR. The
first is generated by :helptags - the hand-written entry landed after
termu7resp-variable, out of sort order - and the second by
runtime/syntax/generator/gen_syntax_vim.vim, as the comment right above the
changed line records. Drop both files.

version.c is not needed either: extra_patches is for patches added by whoever
ships the sources, and the array has held nothing but NULL in this repository
since 7.2. Drop that hunk.

The da1 and osc entries added to block_autocmds() and unblock_autocmds() close
a gap that predates this PR and are not mentioned in the commit message. They
belong in a patch of their own.

Tests

augroup! testRespRGB runs while the autocommand is still defined, so
au_del_group() gives W19 and keeps the autocommand alive under the deleted
group. TermResponseAll then keeps firing into g:got_rgb_resp for the rest of
test_termcodes.vim. Empty the group first, and unlet g:got_rgb_resp when done.

The response the test feeds decodes to "100", which never reaches the
val == 8 path - 313030 would have to be 38. The realistic answer is worth
testing, and so is the unsupported one, which currently produces neither a
variable nor an event.

Documentation details

In autocmd.txt, "correspondingly, can be used. " lost one of the two
spaces after the period.

A new v: variable belongs in version9.txt as well, and the 'termguicolors'
entry in options.txt is where a user looks for this.

@h-east

I disagree that v:termrgbresp should hold the raw response. The scope of this PR is strictly about a positive RGB response (the same behaviour #16490 used to have). Within this scope, if and when a positive RGB response arrives, the response will always have the format DCS 1 + r 5 2 4 7 4 2 = Pr ST where Pr is the hex-encoded value of the RGB capability. I considered storing this format in v:termrgbresp and decided that no information is lost by parsing it into a simple string containing the value.

Ncurses is irrelevant to this PR, this feature deals strictly with terminal response. The specification I used for the XTGETTCAP response is this one https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Device-Control-functions, which in my understanding can't send a boolean value and will translate a numerical value into a string. Therefore, the space of responses is always a string, either containing a single number (e.g. 8, for bits per channel across 3 channels) or three numbers (e.g. 5/6/5, for bits per each channel). I decided that parsing this string is out of scope for this PR, so v:termrgbresp contains the "raw" capability string. The example in the PR description mirrors what #16490 used to do, and is not meant to be an all-encompassing solution (the same way #16490 evidently wasn't). I expect that users can edit the example to fit their needs.

It is true that this PR doesn't provide a mechanism to detect a negative RGB response. This is based closely on #16490 which did nothing when a negative response arrived or no response arrived. I consider it sensible to start Vim in a state that assumes the terminal doesn't support RGB, and configure it to take advantage of RGB when the positive response arrives, because some terminals will never send a response and should be assumed to not support it.

I didn't consider terminalprops() because I aimed to stay consistent with other uses of TermResponseAll. I don't have strong feelings either way. If terminalprops() is preferable to v:termrgbresp I can change the PR to use that.

I didn't consider using "rgb" in lowercase because the capability name is "RGB" in uppercase. I don't have strong feelings either way. If all-lowercase is preferable I can change the PR to use that.

I didn't touch the disabled code too much, under the impression that it was kept because it might still be valuable. I don't have strong feelings either way. If it's preferable to remove it once and for all I can change the PR to do that.

I changed version.c because I use my own patches and like to keep track of which ones I'm using, and expect that the maintainer will remove it when it comes time to merge the PR. (This has happened to my past PRs without issue.)

I agree that da1 and osc fixes should go in a separate patch, but I'm doubtful as to how to go about that. I've previously encountered trouble when I sumitted two patches that worked together, and during some time only one was merged which led to bugs. The fixes also don't address a specific bug, they're simply omissions that I happened to notice while working on this PR, so it's not clear to me how I should present such a patch or what tests (if any) I should add to go along with it.

I agree that augroup! termRespRGB in the test is wrong. It's a typo and should be autocmd! termRespRGB. Aside from that the test is working as intended: it intentionally feeds the unlikely value "100" to avoid the case that the test should fail but passes with a real value fed from elsewhere.

I'd like to hear back on some of my points.

Thanks for the reply. Answers to your points, in your order.

The capability value

You are right - the XTGETTCAP reply is always a string, and ncurses' own
encoding is not what arrives here. Withdrawn. But your reading of the reply
already names two shapes, a single number ("8") and three ("5/6/5"), and the
example in the PR description covers one of them. That is the work I would
rather Vim did once than leave to every vimrc, and it is the same work whether
the variable holds the DCS response or the value pulled out of it.

terminalprops()

Yes, please change the PR to use it. It reports 'y', 'n' or 'u' per property,
so a terminal that answers "5/6/5" reports 'y' like any other, 'u' covers the
terminal that never answers, and the shape of the capability string stays
inside Vim. The TermResponseAll event stays as you have it - what changes is
where a script reads the answer from.

Your reasoning for the negative side is sound: start out assuming no direct
color and move only on a positive answer. terminalprops() records what Vim has
learned so far, which is what 'u' already means for the other entries.

The final call on the interface belongs to @chrisbra, so it is worth waiting
for his view before you rewrite anything.

Lowercase

This one is not a preference. I put two autocommands on the existing da1 event,
au TermResponseAll DA1 and au TermResponseAll da1, and fed the reply: with
'nofileignorecase' only the lowercase one ran, with 'fileignorecase' both did.
The pattern goes through match_file_pat(), which takes rm_ic from p_fic. So a
vimrc with au TermResponseAll RGB works on Unix and one with rgb does not,
while on Windows and macOS both work.

The disabled code

9.1.1114 commented it out with "We may need another way to enable this in the
future". This PR is that other way, so the old auto-enabling code has nothing
left to wait for. Removing it takes the val == 8 test with it, which also
settles the test value question below.

version.c

Someone has to strip that hunk by hand before the change is committed. Please
keep it in your local tree instead.

Splitting the da1 and osc fix

Put it in this same PR as a separate commit, first in the series. The commits
of a PR are applied in order, so the two cannot come apart the way you ran into
before, and each lands with its own message.

On tests: there is no TermResponseAll test in testdir today, and the delayed
firing in unblock_autocmds() has no path a test can reach. block_autocmds() is
called from the clipboard, popup menu, window and undo code, never from
anything that also feeds a terminal reply, and :noautocmd sets 'eventignore'
rather than blocking. The existing six entries went in without a test for the
same reason. A commit message recording that da1 and osc were left out when the
others were added is enough.

The test

The group is testRespRGB, so autocmd! testRespRGB is what you want.

Your reason for feeding "100" is fair, and once the val == 8 test is gone
nothing in the code depends on the value at all. The case still worth adding is
the negative one: feed DCS 0 + r ... ST and assert that nothing changed and
no autocommand fired. That pins down the behavior you describe above.

Thanks, your critique is helpful.

I've given your ideas some thought, and come up with with a plan that sounds sensible to me. I will drop v:termrgbresp in favour of an entry in terminalprops() called 'rgb'. At the time when Vim receives the RGB response, it will check whether the response was positive, and whether the value decodes to '8' or '8/8/8' (the two known formats for "8 bits per component"), and only in that case set the 'rgb' prop to 'y', otherwise 'n'. The TermResponseAll event remains (renamed to "rgb" in lowercase) so that the vimrc can react to the response, should the user want it to.

I'm not yet sure how values besides 8 are reflected in the terminal behaviour. I suspect that they always parse component values from 0 to 255 and either chop less-significant bits off or find the closest representable colour if the display isn't actually 8 bpc. But I haven't found documentation that says this for certain. Either way, 8 bpc is common these days and the direct-color format doesn't afford a greater range than 0 to 255, so I think requiring exactly 8 bpc is reasonable.

What do you think?

The plan is the right shape, but two parts of it will not hold.

'n' cannot be reached

ctlseqs gives the failure reply as "DCS 0 + r ST for invalid requests" - no
name in it. Vim keeps up to ten XTGETTCAP requests outstanding at once,
req_more_codes_from_term() sending while xt_index_out < xt_index_in + 10, so a
bare "DCS 0 + r ST" cannot be attributed to RGB or to any other capability.
That is why got_code_from_term() looks only at code[0] == '1' today.

So 'rgb' will be 'y' or 'u', never 'n'. That still matches what you described:
Vim starts out assuming no direct color, and a vimrc that has waited and still
reads 'u' has its answer.

The value should not decide

Set 'y' on any positive reply and do not read the value at all.

The RGB capability is the terminal reporting that it understands direct color.
The number is how many bits per channel it can show, which is a separate
question - SGR 38:2 carries 0 to 255 per channel whatever the display does with
them, as you suspected. A terminal answering "5/6/5" understands every sequence
'termguicolors' emits and renders them as closely as it can; reporting 'n' for
it drops the user back to 256 colors.

This also drops the parsing: no "8" against "8/8/8", and nothing to revisit
when a terminal answers something neither of us predicted.

The rest of the plan - dropping v:termrgbresp, keeping TermResponseAll with
"rgb" in lowercase - reads right to me.

That makes sense. It raises another question though. If a terminal doesn't respond to XTGETTCAP RGB, but does support direct colour and exposes this through its terminal description (e.g. TERM=xterm-direct), what should count, the number of colours (e.g. Co#16777216), the presence of RGB, or either? The original patch #16490 doesn't seem to do anything useful with RGB from the terminal description, and relies on number of colours for this purpose. It's not obvious to me whether the RGB capability is even exposed through the termcap library.

RGB does not reach Vim through the terminal description

Vim reads capabilities with the termcap-compatible calls - tgetent(),
tgetstr(), tgetflag(), tgetnum() - and those names are two characters. RGB is
a three-character extended capability. Against xterm-direct here:

tgetnum("Co")=16777216  tgetnum("RGB")=-1  tgetflag("RGB")=0
tigetnum("colors")=16777216  tigetnum("RGB")=-2  tigetflag("RGB")=1

The terminfo calls do find it, as a boolean - hence the -2 from tigetnum - but
Vim does not use those. So "the presence of RGB" is not one of the options
unless Vim moves to the terminfo API, which is a change of a different size.
That would explain why #16490 went by the color count.

Either source should count

Co is what the description leaves, and it already lands in t_colors. 16777216
there reports direct color as plainly as RGB would.

The two sources are independent. In #16568 the terminal was xterm under
TERM=xterm-256color, an entry with colors#256 and no RGB, and the XTGETTCAP
answer still turned 'termguicolors' on - xterm answers for itself, not from
the entry $TERM names. Your case is the mirror image: an entry with
colors#16777216 and a terminal that never answers.

So set 'rgb' to 'y' when t_colors reaches 16777216, and on a positive
XTGETTCAP RGB reply. A user who wants direct color does not care which of the
two told Vim.

A note on the value

RGB in the xterm-direct entry is a boolean and carries no number. The "8" and
"8/8/8" shapes exist only in the XTGETTCAP reply - one more reason not to build
the decision on them.

I've begun implementing the changes we agreed on, and I have some questions.

I'm encountering some confusion while implementing the number of colours in the terminal description as a source of direct colour support for terminalprops().rgb. The information is available right away as Vim initializes, before it even needs to wait for a response from the terminal. But when Vim eventually receives a terminal version response it reinitializes all term_props with the "tpr_set_by_termresponse" attribute set to TRUE. If I set this to FALSE for the 'rgb' termprop, it will never get reset (unless the term_prop test override is enabled), even when the 'term' setting changes which I think isn't ideal. If I set this to TRUE, then it gets reset in two ways: setting 'term' (in set_termname) and receiving a terminal version response (in handle_version_response). The obvious way forward here is to set the 'rgb' termprop when there are 16777216 colours in both places, so that it keeps up with changes to 'term', but this sounds kludgy to me, and I want to know what you think.

EDIT: to be clear, the RGB response is downstream of termresponse, so if the terminal responds positively to RGB then the 'rgb' termprop will always be set no matter what happens to the 'term' setting.

When I removed v:termrgbresp, the block/unblock_autocmds functions in autocmd.c lose the variable that helped track whether the 'rgb' TermResponseAll event should fire. The obvious substitute is term_props[TPR_RGB].tpr_status, but term_props is local to term.c. Should I make a new global variable, un-static term_props, ignore block/unblock_autocmds, or is there another more preferable solution?

The color count does not need a copy in term_props

t_colors is a value that can be read at any time, not an answer to remember, so keeping a copy of it in term_props is what creates the reset problem you ran into. Report it where the dictionary is built instead, in f_terminalprops(), and both assignments go away:

	value[0] = term_props[i].tpr_status;
	if (i == TPR_RGB && t_colors == 0x1000000)
	    value[0] = TPR_YES;

term_props then holds the XTGETTCAP answer alone, tpr_set_by_termresponse stays TRUE for it, and the property follows 'term' and t_Co on its own.

An accessor keeps term_props to itself

For the bookkeeping in block_autocmds() and unblock_autocmds(), an accessor in term.c that returns term_props[TPR_RGB].tpr_status is enough. The property only ever goes from unknown to yes, so autocmd.c can hold an int and compare it. Making term_props global is more than this needs.

That also replaces what is still commented out there: the old_termrgbresp declaration and four lines in unblock_autocmds(). Vim uses // rather than /* */.

The property does not depend on FEAT_TERMGUICOLORS

The XTGETTCAP branch in got_code_from_term() sits under #ifdef FEAT_TERMGUICOLORS, while the color count checks in ttest() and handle_version_response() do not. A build without the feature then reports 'y' from the color count but stays at 'u' however the terminal answers. What a terminal supports does not depend on how Vim was built. The branch no longer touches 'termguicolors' now that p_tgc_set is gone, so the #ifdef can go with it.

Two-character names in key_names

In get_term_entries(), key_names[i][2] == 0 reads as a puzzle. Please write NUL and add the reason: RGB is asked of the terminal, and the termcap library has no three-character names.

da1 and osc

Adding them to block_autocmds() and unblock_autocmds() is right, but it is unrelated to RGB and would be easier to see as a commit of its own.

Documentation

In term.txt, the note that :redraw! is needed, and that it clears the intro message, documents a rough edge rather than the feature. Should Vim redraw on its own after an autocommand changed 'termguicolors'? If it should, this note is better left out here and the redraw handled separately.

@h-east

The property only ever goes from unknown to yes

The property may go from yes to unknown during the brief time after the 'term' setting is changed or a terminal version response is received and before the XTGETTCAP RGB response is received. I don't expect this to be a serious problem for block/unblock_autocmds, the worst case is a spurious extra trigger of the TermResponseAll 'rgb' event.

EDIT: I've changed the unblock autocommand to only trigger when the 'rgb' termprop changes from 'u' to 'y', as it normally would if it wasn't blocked.

da1 and osc

Adding them to block_autocmds() and unblock_autocmds() is right, but it is unrelated to RGB and would be easier to see as a commit of its own.

Are you referring to commit 605d740? I don't understand what you want me to change.

Should Vim redraw on its own after an autocommand changed 'termguicolors'? If it should, this note is better left out here and the redraw handled separately.

I would really like to solve the redraw problem before considering this PR complete. I did some testing and found that Vim can draw the intro screen as many as 3 times on startup:

• immediately;
• after receiving the terminal background color response and switching the 'background' setting to dark;
• after receiving the XTGETTCAP Co response and changing the colour count;
• maybe once more if the 'ambiwidth' test sets it to double, but I couldn't test this.

As far as I can tell the redraws are triggered by calls to redraw_asap(UPD_CLEAR), but adding a redraw_asap(UPD_CLEAR) call at the end of did_set_termguicolors doesn't seem to force it to redraw the screen (and it adds another bug: Vim draws the intro before the screen has been put in termcap mode, leaving visible trash after Vim exits). I'd like some help here.

EDIT: Solved below.

Nevermind that last point, I think I've solved it.

@chrisbra

Thanks, I don't think it makes sense in f_termprops().rgb to return the RGB key only when the color count has been set to 16777216, instead let's just return the detected value from the XTGETTCAP query or the TERM value.

To make it clear to me: you are saying that colour count should not affect the value of terminalprops().rgb? The current implementation returns 'y' in either case that colour count is 16777216 or XTGETTCAP response is detected.

Chris is right about t_Co, and it was my suggestion that put that check in
f_terminalprops(), so please drop it and go with what he proposed.

I tested it out with a sample vimrc file:

cat /tmp/vimrc
set nocompatible
set nu
autocmd TermResponseAll * if expand('<amatch>') == 'rgb' |set termguicolors | endif

Running this under xterm sometimes enables termguicolors but mostly doesn't. It looks like a race, the response is sent too early, before that part of the vimrc file was parsed. Not sure how easy it would be to fix this.

Hm, found it. It seems autocmd_busy is set when calling apply_autocmds(), which makes the TermResponseAll being ignored since force is false. This seems to happen when the response arrives while Vim handles the VimEnter autocommand.

But even when I set force=TRUE, it doesn't work because RedrawingDisabled has been set, so the whole redraw_asap() is just skipped.

It looks like a race, the response is sent too early, before that part of the vimrc file was parsed.

I'm having trouble reproducing this. When I use your sample vimrc like vim -u vimrc it works the way I expect every time. When I add a sleep or a busy loop to the toplevel of the vimrc, before the TermResponseAll autocommand, Vim seems to wait with an uninitialized terminal until vimrc finishes running (which makes sense to me, the source_startup_scripts function is called in main before RedrawingDisabled is turned off for the first time and may_req_termresponse is called in vim_main2).

This seems to happen when the response arrives while Vim handles the VimEnter autocommand.

When I add a sleep or a busy loop to the VimEnter autocommand, Vim seems to get as far as sending out the version and foreground/background requests before waiting, to which the terminal replies quickly, but Vim only starts sending xterm-codes after it ends. Same thing seems to happen when I open a file.

I want to understand how you got the behaviour you described. I've found script (from util-linux) extremely helpful for debugging terminal responses, maybe it can help you tell the sequence of events that happens?

See here, on startup, Vim is not completely re-drawn, until I hit a key, then the statusline and command line is drawn.

I'm extremely confused. None of my testing ever saw the cursor stop at the last word of the intro screen. Now and even back when this PR still caused a late redraw for me, the statusline was always drawn and the cursor was always at the beginning of the buffer.

I would really appreciate if you sent the results of running Vim inside script --log-io io.log --log-timing timing.log and reproducing that effect, so that I can have a look at where Vim and the terminal stall.

Will do later, once I am back at my developer machine. I think it may be related to having vim-airline +fugitive installed. I think this vim may be busy handling a VimEnter autocommand when it receives TermResponse result.

here we go:
io.log
timing.log

Where this PR should go

Before more time goes into the redraw race, I want to step back to what the
PR is for. Issue #16327 is about TERM=xterm-direct: the terminal is direct
color, Vim knows that from terminfo, and 'termguicolors' still has to be set
by hand. For that terminal nothing asynchronous is needed. termcapinit()
runs before the vimrc is sourced, so t_colors is already 16777216 there
(measured with this PR's build under TERM=xterm-direct: &t_Co is
16777216 in the vimrc, unless $COLORS overrides it), and
terminalprops().rgb can be 'y' at that point too: set it at the end of
ttest() when t_colors == 0x1000000, as discussed on 2026-09-02. That part
is not in the PR yet; the same run reports rgb as 'u' in the vimrc. With
it, the user of #16327 writes

if terminalprops().rgb == 'y' | set termguicolors | endif

in the vimrc and is done: no autocommand, no race, and the intro screen is
drawn once, in the right colors.

What the XTGETTCAP path adds, and what it costs

Both sources should still count, as I wrote on 2026-08-30: the XTGETTCAP RGB
reply is what covers xterm under TERM=xterm-256color (#16568), which no
terminfo entry reports. But that source is the one that arrives late, and it
comes with everything Chris ran into: the reply arrives after the screen is
drawn, so 'termguicolors' changes under a drawn intro, and it can be parsed
while a VimEnter autocommand is running. In that state
apply_autocmds(..., FALSE, ...) returns at the autocmd_busy check in
autocmd.c, both in got_code_from_term() and in the unblock_autocmds()
replay, so the user's autocommand never runs. Every TermResponseAll event is
fired the same way; RGB is the first one that arrives late enough to show
it, because the XTGETTCAP exchange is the longest.

Fixing that means either forcing the event past autocmd_busy or holding it
back and replaying it later, plus a redraw that survives RedrawingDisabled.
Those are changes to how terminal responses are dispatched in general, and
they deserve a change of their own rather than a fix folded into this one.
That change also has to settle what Chris pointed out on 2026-09-02: once
the event exists, :set t_Co=16777216 changes the value without firing it.

Proposal

1. The t_colors part first, as a PR of its own: terminalprops().rgb set
   at the end of ttest(), the documentation for the vimrc line above, and
   a test. I have this implemented and tested (test_termcodes passes, and
   under TERM=xterm-direct the vimrc reads 'y'); it is four files and
   about fifty lines, and I will open it shortly. That closes Support for Direct Color #16327.
2. This PR then keeps what only it can provide: the da1/osc replay as the
   first commit, the XTGETTCAP RGB reply, TermResponseAll "rgb", and the
   dispatch and redraw handling they need, rebased on the first part.

Chris has already agreed to the terminalprops() interface, so this is a
reordering, not a change of direction.