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

[Sebastian Tennant <sdt@sebyte.me>]

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