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

[Eli Zaretskii]

> 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.

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

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