Subject: bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen

From: Robert Pluim <[email-masked]>
Date: Fri, 17 Mar 2023 16:39:19 +0100

>>>>> On Fri, 17 Mar 2023 14:15:34 +0200, Eli Zaretskii <[email-masked]> said:
    Eli> If the problem persists in Emacs 29, then please tell why you need to
    Eli> use COLORTERM=truecolor at all.  Emacs uses that as fallback, in case
    Eli> all the other known methods of specifying true color via terminfo
    Eli> didn't work.  This fallback relies on an assumption regarding the
    Eli> commands to send to the terminal to turn on and off the colors, see
    Eli> the file term.c in the Emacs source tree around line 4160.  The other
    Eli> known methods of specifying support for true color use
    Eli> 'setf24'/'setb24' capabilities, or the 'RGB' flag is set by terminfo.

    Eli> So setting COLORTERM=truecolor is the responsibility of the user: the
    Eli> user should _only_ set it if the text-mode terminal actually supports
    Eli> true color using the commands Emacs expects to work in that case, but
    Eli> Emacs cannot detect that without COLORTERM=truecolor being set.  Is
    Eli> that your case?

    Eli> Finally, please show the display produced by "M-x list-colors-display"
    Eli> in both cases: when COLORTERM=truecolor is and isn't set.  It is
    Eli> important for us to know how many colors Emacs uses in each situation.

For reasons unknown to me, I actually have COLORTERM=truecolor set in
my environment, which tickles this issue. But the only reason it does
so is because under screen by default I get
TERM=screen.xterm-256color. If I do

TERM=xterm-256color src/emacs -Q -nw

then I get 24bit colour (according to `display-color-cells')

I guess we could drop the 'screen.' prefix in
`init_display_interactive', although that does feel like a hack.

Robert
--