[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen b
From: |
Sebastian Tennant |
Subject: |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) |
Quoth Eli Zaretskii <eliz@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@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).
- bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen, (continued)
- bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen, Robert Pluim, 2023/03/17
- bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen, Eli Zaretskii, 2023/03/17
- bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen, Robert Pluim, 2023/03/18
- bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen, Eli Zaretskii, 2023/03/18
- bug#62237: 28.1 or higher: 24-bit true color breaks colours in Emacsen built without X under GNU Screen, Robert Pluim, 2023/03/18
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