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

[Sebastian Tennant]

Quoth Robert Pluim <rpluim@gmail.com>
on Mon, 20 Mar 2023 09:36:39 +0100:
>> […]
>> Yes, I think in emacs-29.  Why "radical"?
>
> Changing the interpretation of the userʼs TERM seems pretty radical
> to me, even if it will tend to improve usersʼ experience.
>
>>> I guess we could do something with not checking COLORTERM under screen
>>> instead.
>
>> That's a separate issue, from where I stand.  Users can unset
>> COLORTERM, but their true terminal type will still be "hidden"
>> behind the "screen." prefix, won't it?  The terminal type is about
>> more than just the colors.  Or does terminfo know about this
>> "screen." business?
>
> 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).

> Perhaps the best thing to do is put an entry in etc/PROBLEMS?

How about something like this:

 Emacs >= 28.1 respects the value of environment variable COLORTERM
 and if it is set to 'truecolor', expects the terminal to support
 24-bit true colour.

 GNOME Terminal supports true colour and, unnecessarily, sets
 COLORTERM=truecolor to make this clear.

 GNU Screen 4.X does ̲n̲o̲t support true colour.  If you start Emacs at
 Screen start time (via an entry in your .screenrc), Emacs will
 inherit the environment and, because of COLORTERM=truecolor, assume
 the terminal, i.e. the screen, supports true colour.  This will
 result in broken colours in Emacs.

 The simplest solution is to unset COLORTERM in the environment before
 launching screen.

Or words to that effect.