fix(nvim): judge the real rendering chain, not $TERM (completes #53) - #55
Merged
Merged
Conversation
1.11.8 gated termguicolors on $TERM, which inside tmux is always tmux's
own (tmux-256color). The gate therefore never fired in tmux - the case
the report actually came from - while tmux quantized nvim's truecolor
down to the client's palette. Measured through an 8-colour client:
blue-on-black across 9.8% of the screen.
_chain_colors() now asks tmux for #{client_termname} and counts that
terminal's colours with tput -T. Counting beats matching the name:
alacritty and xterm-kitty are truecolor terminals with no '256' in them.
Also drop the colorscheme switch 1.11.8 added. habamax and retrobox set
ctermfg=251/ctermbg=234, and BOTH collapse to black at 8 colours - 67%
of the screen black-on-black, far worse than the bug. Keeping nightfly
with termguicolors off renders in the terminal's own fg/bg: 0.4%.
Refs #53
The arm typed :call writefile(...) after a fixed sleep, which raced a cold nvim start in CI and reported 'produced no result - cannot tell'. nvim now writes the answer from -c, and the arm polls for the file instead of sleeping a guessed amount. Re-red-proofed: reinstating the tmux blind spot still reddens this arm alone.
The arm still produced no result in CI while passing locally under a clean environment, so the cause is the container, not timing. Two changes: it now writes through the same lua io.open form probe.lua already uses successfully on nvim 0.10.4 in CI (writefile() wants a List of strings and was being handed a number - unproven as the cause, both forms work on 0.12 here), and on failure it prints the pane state and the pane's last output instead of only saying it could not tell.
CI diagnostics showed the real cause: the pane's shell is the login shell, which after this repo's install is zsh, and with no ~/.p10k.zsh it opens powerlevel10k's configuration wizard - so send-keys typed into the wizard. It could not reproduce here because this box already has ~/.p10k.zsh. The pane now runs a script that waits for a flag file and then starts nvim, so nothing depends on the login shell or on keystroke timing. The client is held attached through a fifo: with stdin on /dev/null, script hit EOF at once and the session was destroyed about two seconds in, which is why pinning a bare bash alone made the arm skip. Re-red-proofed after the rewrite: the tmux blind-spot mutation still reddens this arm alone.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
v1.11.8 fixed only half of #53, and the half it fixed was the half that was not
happening. This fixes the real chain and reverts the part of 1.11.8 that was
measured actively harmful.
Why 1.11.8 missed it
1.11.8 gated
termguicolorson$TERM. Inside tmux$TERMis always tmux'sown (
tmux-256color), regardless of what the client is - so the gate saw "256",concluded the chain was capable, and never fired. Meanwhile tmux quantizes
whatever nvim emits down to the attached client's palette.
Measured inside tmux with an 8-colour client (
TERM=xterm), scoring the finalscreen through a real terminal emulator (pyte), counting only nvim's rows:
blue/blackx72The second finding: 1.11.8's colorscheme switch was worse than the bug
1.11.8 also swapped the scheme to
habamaxon the fallback path. habamax setsctermfg=251/ctermbg=234, and both collapse to black in tmux's 256->8conversion. Same harness, same screen:
termguicolorsoffdefault, offtermguicolorson (the bug)So the gate now touches
termguicolorsand nothing else. Keeping nightfly withtruecolor off costs its colours - it defines no cterm values - but renders in the
terminal's own fg/bg, which is readable by construction.
How the chain is judged now
_chain_colors()asks tmux for#{client_termname}when$TMUXis set, thencounts that terminal's colours with
tput -T <name> colors. Counting beatsmatching the name:
alacrittyandxterm-kittyare truecolor terminals whosenames carry no
256, and downgrading them would be a regression. Confirmedpositively on all four chains:
Verified
tests/nvim-colour-fallback.shrewritten to four arms: direct low-colour, direct256-colour, inside tmux with an 8-colour client, and a guard against adopting a
232-255 grey scheme. Each arm red-proofed, and each mutation reddens only the arms
it should:
termguicolors = true$TMUX)ctermfg=251/ctermbg=234Restored tree:
RESULT: PASSED (4 checks ran, none skipped).Also:
bash test.sh workstation61/62, 0 failures, 1 skip (unchanged);tests/lint-workflows.shPASSED;tests/ci-gate-covers-all.pypasses;shellcheck -S warning clean.
Measurement notes, because three harnesses were wrong first
Recorded so the numbers above can be trusted and the traps are not repeated:
#{client_termname}empty atthe moment the config reads it, so the fix cannot fire and the arm proves
nothing. A client must be attached first.
and tmux status bar dominate the number. Only the final screen, reconstructed by
an emulator, is meaningful.
teardown clear - that scored 73 cells and looked like a clean pass.
scriptinherits the loop's stdin and eats the remaining input,so only the first candidate ran.
xterm-kittyhas no terminfo on the dev box, so that row was a failed attach,not a result; it is excluded rather than reported as "no colour".