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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#62237: closed (28.1 or higher: 24-bit true color breaks
 colours in Emacsen built without X under GNU Screen)
Date: Thu, 23 Mar 2023 08:06:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 23 Mar 2023 10:05:27 +0200
with message-id <83a6036gfs.fsf <at> gnu.org>
and subject line Re: bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen
has caused the debbugs.gnu.org bug report #62237,
regarding 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
62237: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62237
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Sebastian Tennant <sdt <at> sebyte.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1 or higher: 24-bit true color breaks colours in Emacsen built
 without X under GNU Screen
Date: Fri, 17 Mar 2023 09:41:36 +0000

Hello there,

Summary: Support for 24-bit true colour, added in Emacs 28.1, breaks
         colours in Emacsen built without X support and running under
         GNU Screen (v4.08.00).

Steps to reproduce:

 1. Build Emacs >= 28.1 without X support.  The two configurations I have
    tested are below:

     ./configure\                          ./configure\
       --prefix=[…]\                          --prefix=[…]\
       --enable-check-lisp-object-type\       --enable-check-lisp-object-type\
       --disable-acl\                         --disable-acl\
       --without-dbus\                        --without-all\
       --without-gconf\                       --without-x\
       --without-gif\                         --with-file-notification=yes\
       --without-gsettings\                   --with-gnutls\
       --without-jpeg\                        --with-gpm\
       --without-modules\                     --with-json\
       --without-png\                         --with-mailutils\
       --without-rsvg\                        --with-modules\
       --without-selinux\                     --with-native-compilation\
       --without-sound\                       --with-libsystemd\
       --without-tiff\                        --with-small-ja-dic\
       --without-x\                           --with-sqlite3\
       --without-xpm\                         --with-threads\
                                              --with-xml2\
                                              --with-zlib\

 2. Launch a terminal program (e.g. GNOME Terminal) and run GNU Screen
    (bypassing any .screenrc):

     $ touch foo
     $ screen -c foo

 3. Run Emacs with 24-bit true colour active and observe the broken colours:

     $ COLORTERM=truecolor ./src/emacs -Q

    Screenshot: https://download.sebyte.me/misc/truecolor-active.png

 4. Run Emacs with 24-bit true colour inactive and observe the correct colours:

     $ COLORTERM= ./src/emacs -Q

    Screenshot: https://download.sebyte.me/misc/truecolor-inactive.png

[Message part 3 (message/rfc822, inline)]

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

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: sdt <at> sebyte.me,  62237 <at> debbugs.gnu.org
> Date: Mon, 20 Mar 2023 15:51:27 +0100
> 
> >>>>> On Mon, 20 Mar 2023 16:23:28 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     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 :-)

I have now added a PROBLEMS entry about this issue on the emacs-29
branch, and I'm closing this bug.

Thank you both for all the useful information about the various
aspects of the issue.  I tried to use all of that in the PROBLEMS
entry.

Previous Next

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