--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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@gmail.com>
> Cc: sdt@sebyte.me, 62237@debbugs.gnu.org
> Date: Mon, 20 Mar 2023 15:51:27 +0100
>
> >>>>> On Mon, 20 Mar 2023 16:23:28 +0200, Eli Zaretskii <eliz@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.
--- End Message ---