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

[Robert Pluim]

>>>>> On Mon, 20 Mar 2023 16:23:28 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: sdt@sebyte.me,  62237@debbugs.gnu.org
    >> Date: Mon, 20 Mar 2023 15:08:14 +0100
    >> 
    >> >>>>> On Mon, 20 Mar 2023 14:15:35 +0200, Eli Zaretskii <eliz@gnu.org> 
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
--