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

Full log

Message #38 received at 62237 <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Tennant <sdt <at> sebyte.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62237 <at> debbugs.gnu.org
Subject: Re: bug#62237: 28.1 or higher: 24-bit true color breaks colours in
 Emacsen built without X under GNU Screen
Date: Fri, 17 Mar 2023 20:18:47 +0000

Quoth Eli Zaretskii <eliz <at> gnu.org>
on Fri, 17 Mar 2023 21:02:44 +0200:
>>> No, Emacs 30 is good enough.  (Your report says Emacs 28.1, which
>>> is why I asked.)
>>
>> It's easy to miss the "or higher".
>
> The "or higher" is not useful because it says nothing about the
> versions you actually tested.  It could be Emacs 28.2, for example.
> Please always tell all the details without assuming that our crystal
> balls are clear enough to see them.

Fair enough.  Apologies for the lack of clarity.

>>> What is TERM set to on that system?
>>
>> In a plain GNOME Terminal, i.e. outside screen:
>>
>>  xterm-256color
>
> That's 256 colors, not 64-bit true-color terminal, AFAIU.

You may be right.  My understanding is very limited in this area.

>>> It also says that your terminal actually supports only 88 colors.
>>
>> How do you infer that?
>
> By looking at the color names.

Ah... OK.

>>> So you should unset COLORTERM in your environment
>>
>> That's precisely the fix I discovered yesterday.
>
> Then I guess this bug can be closed?

I suppose so.

It felt like an Emacs bug because I was happily using Emacs 27.2 and
when I upgraded to 28.1, the colours were broken all of a sudden, but
yes, the fault may be with screen.

>> According to:
>>
>>  https://github.com/termstandard/colors
>>
>> command:
>>
>>  $ printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n"
>>
>> shows your terminal is capable of truecolor if the word TRUECOLOR is
>> printed in brown.  According to the result of this test, GNOME
>> Terminal (3.38.3) _is_ truecolor enabled.
>
> Which standard of true color does it support?

I don't know how to answer this question.

>> I can observe the same broken colours in xterm (under the same
>> conditions) shipped by Debian bullseye.
>>
>> I'm sure it has to do with screen and will investigate whther or
>> not my version of screen supports truecolor.
>
> Thanks.

Haven't had time to investigate yet, but will do tomorrow.


Quoth Eli Zaretskii <eliz <at> gnu.org>
on Fri, 17 Mar 2023 21:50:16 +0200:
>>> What is TERM set to on that system?
>>
>> In a plain GNOME Terminal, i.e. outside screen:
>>
>>  xterm-256color
>
> And what is it set to _inside_ screen?

I set it to screen.gnome in my .screenrc, but this has no bearing on
the issue, i.e. if I comment out the ‘term screen.gnome’ line in my
.screenrc, TERM is set to screen.xterm-256color (as Robert pointed
out) and the colors are still broken.

Incidentally, I use screen.gnome because it limits the colors to eight
(and I prefer the simplicity of just eight colors).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.