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
Reported by: Sebastian Tennant <sdt <at> sebyte.me>
Date: Fri, 17 Mar 2023 09:42:02 UTC
Severity: normal
Found in version 28.1
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 62237 <at> debbugs.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: 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.
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 2 years and 57 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.