From b49ef9f2c6f3408e3bc275d52990fac154182d97 Mon Sep 17 00:00:00 2001 From: Jean-Pierre Martineau Date: Sun, 19 Jul 2026 01:30:59 -0400 Subject: [PATCH] Render bridge: NO_COLOR must not strip the TUI's hues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The five "pre-existing" test failures (four corner-glow, one message- paths muted-hash assertion) were all one thing: under a NO_COLOR environment, Rich's console honoured it inside the TUI's headless render bridge and stripped every named-style colour — but that console is a rasterizer whose ANSI prompt_toolkit re-parses, not terminal output, and the TUI's hues are semantics (node identity, recency heat), not decoration. The bridge now pins no_color=False; the scripted CLI's real console (theme.build_console) keeps honouring NO_COLOR, where it belongs. Nothing was wrong with the tests or the hash-widget commit they seemed to implicate. Co-Authored-By: Claude Fable 5 --- meshterm/ui/tui/render.py | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/meshterm/ui/tui/render.py b/meshterm/ui/tui/render.py index 5568f08..ea3b5b3 100644 --- a/meshterm/ui/tui/render.py +++ b/meshterm/ui/tui/render.py @@ -42,6 +42,12 @@ def _console(width: int) -> Console: file=StringIO(), force_terminal=True, color_system="truecolor", + # This console is a rasterizer, not terminal output: its ANSI is re-parsed + # by prompt_toolkit, and the TUI's hues are semantics (node identity, + # recency heat), not decoration. So a NO_COLOR environment must not strip + # them here — the scripted CLI's real console (theme.build_console) is the + # one that honours NO_COLOR. + no_color=False, highlight=False, soft_wrap=False, )