Skip to content

fix(foot): use foot-direct terminfo for 24-bit truecolor support - #11371

Open
Irfrit wants to merge 1 commit into
omacom:quattrofrom
Irfrit:fix/foot-terminfo-truecolor
Open

Irfrit wants to merge 1 commit into
omacom:quattrofrom
Irfrit:fix/foot-terminfo-truecolor

Conversation

@Irfrit

@Irfrit Irfrit commented Sep 11, 2026 •

Copy link
Copy Markdown

Problem

When opening Emacs / Doom Emacs in terminal mode (emacsclient -t / ec) inside Foot, the entire editor background turns blue andcolors are distorted.

This happens because config/foot/foot.ini overrides term=xterm-256color. Unlike Neovim (which checks $COLORTERM), GNU Emacs strictly checks the terminfo database for $TERM. Seeing only 256 colors, it downgrades and rounds dark RGB backgrounds (like #0b0d11) to ANSI Color 17 (Navy Blue).

Fix

Set term=foot-direct in config/foot/foot.ini.

This enables native 24-bit Truecolor in Foot's terminfo, fixing the blue background in Emacs and ensuring proper color fidelity across all terminfo-aware CLI/TUI applications (like btop, htop, delta, etc.) with zero color degradation.

@omarchybot omarchybot added the bug Something isn't working label Sep 27, 2026
@omarchybot

Copy link
Copy Markdown
Collaborator

Reviewed at 9038144, against quattro at 31bd80d, on a disposable Omarchy worker with Emacs 31.1 and foot 1.28.

The bug is real, and this change does make it go away. An Emacs daemon started without COLORTERM, reached with emacsclient -t under TERM=xterm-256color, paints a #0b0d11 background as ESC[48;5;17m, which is colour 17, navy. With TERM=foot-direct the same client gets ESC[48:2::11:13:17m, the real colour. ./test/cli passes on the head.

But TERM is not the cause. Plain emacs -nw under xterm-256color already gets 24-bit colour, because foot exports COLORTERM=truecolor and Emacs honours it. The navy only appears through the daemon: Emacs reads COLORTERM from the daemon's own environment, not from the client's terminal. A daemon started with COLORTERM=truecolor gives emacsclient -t the correct ESC[48;2;11;13;17m under unchanged xterm-256color. On Omarchy that daemon comes from the omarchy-emacs package, so giving the daemon COLORTERM=truecolor fixes the bug where it starts.

Changing TERM for every program in foot costs more than this bug is worth:

  • SSH. ssh forwards TERM, and ordinary servers do not know foot-direct. In a stock debian:stable-slim, clear says 'foot-direct': unknown terminal type., and ubuntu:24.04 has no foot terminfo entries at all. That is why config/alacritty/alacritty.toml sets xterm-256color and config/ghostty/config turns on ssh-env. With this change, foot would be the one Omarchy terminal that breaks on a remote host.
  • Colours 8 to 255. foot-direct reads every colour number from 8 up as an RGB value. TERM=foot-direct tput setaf 9 emits ESC[38:2::0:0:9m (nearly black) where xterm-256color emits bright red (ESC[91m). Any terminfo-driven program that picks a palette colour from 8 to 255 gets a dark blue-black instead. Omarchy's own scripts use no such colours.

No second opinion ran on this item. Codex Medium answered the availability ping, but the review was refused because the day's review budget was spent, so these findings are one model's (Claude Opus 5.5).

This is waiting on the maintainer: whether to fix the Emacs daemon's environment in omarchy-emacs instead, or to accept the SSH and palette trade-off here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants