From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 14:15:35 +0200 Message-ID: <83lejr8vq0.fsf@gnu.org> References: <87sfe390kv.fsf@sebyte.me> <83h6ujefq1.fsf@gnu.org> <87wn3fs7yw.fsf@gmail.com> <833563e3xc.fsf@gnu.org> <87sfe3s26k.fsf@gmail.com> <83pm97cin8.fsf@gnu.org> <87o7oqsa36.fsf@gmail.com> <83v8iybf49.fsf@gnu.org> <871qlms7h3.fsf@gmail.com> <83r0tmbb11.fsf@gnu.org> <87sfe2qo5u.fsf@gmail.com> <83lejub31r.fsf@gnu.org> <87o7onrf8o.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36971"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sdt@sebyte.me, 62237@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 20 13:16:24 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1peER5-0009Ja-4u for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Mar 2023 13:16:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1peEQl-00074X-CJ; Mon, 20 Mar 2023 08:16:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peEQk-00074N-Ci for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2023 08:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1peEQk-00078O-3L for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2023 08:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1peEQj-0006gS-Ve for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2023 08:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Mar 2023 12:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62237 X-GNU-PR-Package: emacs Original-Received: via spool by 62237-submit@debbugs.gnu.org id=B62237.167931453525658 (code B ref 62237); Mon, 20 Mar 2023 12:16:01 +0000 Original-Received: (at 62237) by debbugs.gnu.org; 20 Mar 2023 12:15:35 +0000 Original-Received: from localhost ([127.0.0.1]:53868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1peEQJ-0006fl-68 for submit@debbugs.gnu.org; Mon, 20 Mar 2023 08:15:35 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1peEQH-0006fW-Id for 62237@debbugs.gnu.org; Mon, 20 Mar 2023 08:15:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peEQB-0006zN-SH; Mon, 20 Mar 2023 08:15:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=5uiV8G4paFPydwnq3FK2YcqyanSkaJtq9RA0koJJ0v8=; b=UcFQoxX2Fih4LC8htIE5 jBInffiP0/du7Z3dozcf1Z1OaIcDYpzUjg10zr5hgPo/rFUEp9n/iFKV9K34aD7FJDLjLCNTOmuY/ iQtskojvbzU3MAby4lnEAudk12KHG2BjVCO8UphnK0LJHZBxTfGvOch1EOrjSOES5t8FQOIs3iCWM Co2x/4ZDaYWPJ7dMK2RH9y59oU0VQghXJkAXNTpxS8NYPSfyCd5Cx8o3vo7iU/Gfbx4PF64ngNvm0 6nK9gyRil9/Y1mLfP+CNIt9ztUfzfyF92RTtWjmqBlVZUuHXF5f5tzyJafxJWjLyvValxSj4DpXHi Meon0AFl3dfKgA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peEQA-0005uZ-Vc; Mon, 20 Mar 2023 08:15:27 -0400 In-Reply-To: <87o7onrf8o.fsf@gmail.com> (message from Robert Pluim on Mon, 20 Mar 2023 09:36:39 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258283 Archived-At: > From: Robert Pluim > Cc: sdt@sebyte.me, 62237@debbugs.gnu.org > Date: Mon, 20 Mar 2023 09:36:39 +0100 > > >>>>> On Sat, 18 Mar 2023 15:29:52 +0200, Eli Zaretskii said: > > >> From: Robert Pluim > >> Cc: sdt@sebyte.me, 62237@debbugs.gnu.org > >> Date: Sat, 18 Mar 2023 12:44:45 +0100 > >> > >> >>>>> On Sat, 18 Mar 2023 12:37:30 +0200, Eli Zaretskii said: > >> > Eli> Then I guess we should install your proposed fix in init_tty. > >> > >> In emacs-29? That seems a bit radical. Patch below in any case > > Eli> 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. If screen.FOO is not recognizable while FOO is, then we cannot possibly break anything by this change, however radical. (But it sounds like I misunderstood what is going on here, see below.) > >> I guess we could do something with not checking COLORTERM under screen > >> instead. > > Eli> That's a separate issue, from where I stand. Users can unset > Eli> COLORTERM, but their true terminal type will still be "hidden" behind > Eli> the "screen." prefix, won't it? The terminal type is about more than > Eli> 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. Are the screen.$TERM files different from the corresponding $TERM ones? If so, what are the differences? And if screen.$TERM files are available in the terminfo DB, then why did you suggest to do something in init_tty in the first place? Also, what about the lisp/term/ files -- are we loading the right files when TERM -s set to screen.SOMETHING? should we? > Perhaps the best thing to do is put an entry in etc/PROBLEMS? About what? If screen.FOO files are available, then everything should already work correctly OOTB, no? Or what am I missing here?