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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: sdt <at> sebyte.me, 62237 <at> debbugs.gnu.org
Subject: bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen
Date: Mon, 20 Mar 2023 16:23:28 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.