Le 14 mai 2024 à 19:33, Eli Zaretskii <eliz@gnu.org> a écrit :
Emacs doesn't have a lisp/term/wezterm.el file, so the question is
what is your TERM environment variable set to?
My bad, the TERM environment variable is set to xterm-256color
there. But infocmp -x still does not show any setf24 or setb24,
only setab and setaf again, this time (it seems to be the exact same)
#+begin_src
setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
#+end_src
You expect the terminal to obey the X RGB color specification
directly, but that is not how TTY color support works in Emacs. Emacs
approximates each X color using the colors that the terminal actually
supports. So we should start by looking at the color setup and how
many colors that yields. What does "M-x list-colors-display" produce?
What bothers me is that there seems to be an inconsistency there. I expect
Emacs in a terminal that supports 24-bit to show the colour `#000000` as
pitch black. Instead it’s the 0th colour of the terminal emulator palette. All
the colours seems to be displayed exactly as they should, except the
first 8 ones.
To answer your question, `M-x list-colors-display` seems to show the
maximum amount possible (all the colours are named like « goldenrod »
etc.), but the first 8 ones definitely don’t look right. I am attaching 2 screenshots, one
from my reproduction script, and the first page of list-colors-display, where we can see
that the black `#000000` is not dark at all.
I hope this will work not too horribly with the apple mail client (for the record, I’m using
the emacs-plus recipe, but I don’t think any patch is touching the display code for this
https://github.com/d12frosted/homebrew-emacs-plus/tree/master/patches/emacs-30 )
