unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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 08:57:45 +0000	[thread overview]
Message-ID: <87v8iv94vq.fsf@sebyte.me> (raw)
In-Reply-To: <87o7onrf8o.fsf@gmail.com> (Robert Pluim's message of "Mon, 20 Mar 2023 09:36:39 +0100")

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.





  reply	other threads:[~2023-03-20  8:57 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8iv94vq.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).