Module ui 

The signs the hooks print.

Colour is the terminal’s decision, not ours. These used to be 256-colour codes — 38;5;112, 38;5;160, 38;5;208 — which live in the fixed xterm cube. A terminal theme remaps only indices 0–15; anything above renders identically whatever palette the user chose. So a carefully themed terminal was being overridden by three numbers picked years ago.

The base ANSI colours ARE theme-controlled, so 32 means “whatever this terminal calls green”. That is the whole fix: output follows a vivid palette, a Solarized profile or a high-contrast one, without reading any configuration.

LS_COLORS is deliberately NOT consulted. It maps FILE TYPES — di, ex, mi — while this output needs ok/warning/error. There is no honest correspondence, and the nearest candidates are worse than nothing: under vivid lava, mi and or are dark grey on red, which as a foreground for ✗ is close to invisible.

The earlier note here said the signs were “kept byte-identical” with the zsh originals so a user could not tell which implementation ran. That mattered during the migration and no longer does — no zsh hook remains to match.

Functions

colors_enabled

Does the caller want colour at all?

error_sign

highlight

Emphasise a fragment inside a message, in the terminal’s own accent.

sanitize

Text from a repository, made safe to hand a terminal.

sanitize_path

The same, for a path that came off a walk of somebody’s disk.

valid_sign

The glyph carries the meaning and the colour only reinforces it, so under NO_COLOR — and for the ~8% of men with red-green colour vision deficiency — ✓ ✗ ! stay distinguishable on their own.

warning_sign