From: Sebastian Tennant <sdt@sebyte.me>
To: Robert Pluim <rpluim@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 62237@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:26:33 +0000 [thread overview]
Message-ID: <874jqf8k3q.fsf@sebyte.me> (raw)
In-Reply-To: <87y1nrpjbk.fsf@gmail.com> (Robert Pluim's message of "Mon, 20 Mar 2023 15:51:27 +0100")
Quoth Eli Zaretskii <eliz@gnu.org>
on Mon, 20 Mar 2023 14:17:03 +0200:
>>> I have both a 'screen.xterm-256color' and a 'xterm-256color'
>>> terminfo file. I donʼt think terminfo does any prefix stripping,
>>> as thereʼs a whole bunch of screen.$TERM files, which would be
>>> unnecessary if stripping were happening.
>>
>> FWIW, I agree that stripping the 'screen.' prefix isn’t the correct
>> thing to do. (Let's not forget that the issue seems to have bitten
>> only one person in well over a year).
>
> Why did this bite you?
My suggestion for an entry in etc/PROBLEMS:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62237#80
is the best explanation I can come up with.
> Don't you have those screen.FOO files?
These are installed by Debian package ncurses-term:
$ ls -l /usr/share/terminfo/s/screen.x*
lrwxrwxrwx 1 root root 20 Jan 1 2021 /usr/share/terminfo/s/screen.xterm-new -> screen.xterm-xfree86
-rw-r--r-- 1 root root 1607 Jan 1 2021 /usr/share/terminfo/s/screen.xterm-r6
-rw-r--r-- 1 root root 3675 Jan 1 2021 /usr/share/terminfo/s/screen.xterm-xfree86
https://packages.debian.org/bullseye/all/ncurses-term/filelist
and these by package ncurses-base:
$ ls -l /lib/terminfo/s/screen.x*
-rw-r--r-- 1 root root 3573 Jan 1 2021 /lib/terminfo/s/screen.xterm-256color
https://packages.debian.org/bullseye/all/ncurses-base/filelist
I've no idea why file screen.xterm-256color belongs to a different
package (and is installed in a different directory).
In case it helps, there's a lengthy discussion about
screen.xterm-256color here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854414
Quoth Eli Zaretskii <eliz@gnu.org>
on Mon, 20 Mar 2023 16:23:28 +0200:
>> 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?
Why it is set remains unclear.
> Is it GNOME which sets it, or is it something else?
It is set by VTE:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62237#71
next prev parent reply other threads:[~2023-03-20 16:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 9:41 bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen Sebastian Tennant
2023-03-17 12:15 ` Eli Zaretskii
2023-03-17 15:39 ` Robert Pluim
2023-03-17 16:30 ` Eli Zaretskii
2023-03-17 17:44 ` Robert Pluim
2023-03-17 18:55 ` Eli Zaretskii
2023-03-18 9:05 ` Robert Pluim
2023-03-18 9:09 ` Eli Zaretskii
2023-03-18 10:02 ` Robert Pluim
2023-03-18 10:37 ` Eli Zaretskii
2023-03-18 11:44 ` Robert Pluim
2023-03-18 13:29 ` Eli Zaretskii
2023-03-20 8:36 ` Robert Pluim
2023-03-20 8:57 ` Sebastian Tennant
2023-03-20 12:17 ` Eli Zaretskii
2023-03-20 12:15 ` Eli Zaretskii
2023-03-20 14:08 ` Robert Pluim
2023-03-20 14:23 ` Eli Zaretskii
2023-03-20 14:51 ` Robert Pluim
2023-03-20 16:26 ` Sebastian Tennant [this message]
2023-03-23 8:05 ` Eli Zaretskii
2023-03-18 10:34 ` Sebastian Tennant
2023-03-18 11:38 ` Robert Pluim
2023-03-18 15:01 ` Sebastian Tennant
2023-03-18 15:13 ` Eli Zaretskii
2023-03-18 17:56 ` Sebastian Tennant
2023-03-18 18:35 ` Sebastian Tennant
2023-03-17 16:20 ` Sebastian Tennant
2023-03-17 16:42 ` Eli Zaretskii
2023-03-17 18:31 ` Sebastian Tennant
2023-03-17 19:02 ` Eli Zaretskii
2023-03-17 19:50 ` Eli Zaretskii
2023-03-17 20:18 ` Sebastian Tennant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jqf8k3q.fsf@sebyte.me \
--to=sdt@sebyte.me \
--cc=62237@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.