Subject: Re: 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: Mon, 20 Mar 2023 15:51:27 +0100

>>>>> On Mon, 20 Mar 2023 16:23:28 +0200, Eli Zaretskii <[email-masked]> said:

    >> From: Robert Pluim <[email-masked]>
    >> Cc: [email-masked],  [email-masked]
    >> Date: Mon, 20 Mar 2023 15:08:14 +0100
    >> 
    >> >>>>> On Mon, 20 Mar 2023 14:15:35 +0200, Eli Zaretskii <[email-masked]> said:
    >> 
    >> >> Perhaps the best thing to do is put an entry in etc/PROBLEMS?
    >> 
    Eli> About what?  If screen.FOO files are available, then everything should
    Eli> already work correctly OOTB, no?  Or what am I missing here?
    >> 
    >> If everything worked OOTB, then yes, but our handling of COLORTERM is
    >> still problematic. If we could delay the 24bit colour support decision
    >> until weʼre in lisp/term I think that would help.

    Eli> So the only real problem is COLORTERM=truecolor, and if it is not set,
    Eli> then everything works reasonably well?  If so, why is COLORTERM set in
    Eli> this case?  Is it GNOME which sets it, or is it something else?

Itʼs either GNOME or gnome-terminal. xterm doesnʼt get it set.

    Eli> COLORTERM support was added because it reportedly helped in some
    Eli> real-life cases.  If it turns out it gets in the way in other cases,
    Eli> we need either find a way of detecting those problematic cases where
    Eli> we process COLORTERM, or ask users to unset the variable if it causes
    Eli> trouble.  I don't see how we could defer processing COLORTERM to
    Eli> later, as knowing how many colors Emacs can work with is necessary
    Eli> very early into startup; too many things will break or work
    Eli> incorrectly if we defer that to later.

OK. Still sounds like etc/PROBLEMS to me :-)

Robert
--