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#69598: 29.2; colour support based on $TERM value not terminfo database Date: Fri, 08 Mar 2024 17:09:51 +0200 Message-ID: <86sf10zrnk.fsf@gnu.org> References: <202403062301.426N1ms7277304@zeus.jtan.com> <86o7bqk06u.fsf@gnu.org> <202403071732.427HWear369011@zeus.jtan.com> <86sf120w9y.fsf@gnu.org> <202403071831.427IVMWs374766@zeus.jtan.com> <86plw5268n.fsf@gnu.org> <202403071959.427JxJTO382071@zeus.jtan.com> <86le6t247d.fsf@gnu.org> <202403072145.427LjkS8393330@zeus.jtan.com> <86jzmd19mg.fsf@gnu.org> <202403081136.428BaKSG077496@zeus.jtan.com> <86zfv8zzdv.fsf@gnu.org> <202403081423.428ENSpk162347@zeus.jtan.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33399"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69598@debbugs.gnu.org To: chohag@jtan.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 08 16:11:10 2024 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 1ribsL-0008Vl-MQ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Mar 2024 16:11:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ribrl-0002U6-VR; Fri, 08 Mar 2024 10:10:33 -0500 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 1ribrj-0002Sq-EC for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 10:10:31 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ribrj-0001sU-6G for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 10:10:31 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ribsF-0002N5-7q for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 10:11:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Mar 2024 15:11:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69598 X-GNU-PR-Package: emacs Original-Received: via spool by 69598-submit@debbugs.gnu.org id=B69598.17099106369046 (code B ref 69598); Fri, 08 Mar 2024 15:11:03 +0000 Original-Received: (at 69598) by debbugs.gnu.org; 8 Mar 2024 15:10:36 +0000 Original-Received: from localhost ([127.0.0.1]:59270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ribrn-0002Lq-Rw for submit@debbugs.gnu.org; Fri, 08 Mar 2024 10:10:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ribrl-0002La-Na for 69598@debbugs.gnu.org; Fri, 08 Mar 2024 10:10:34 -0500 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 1ribr8-0001Rk-Ke; Fri, 08 Mar 2024 10:09:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gbcX3ArQjiSdLBTw6K9tBsQGk9ccO3Mg6k3XA0ttp2Q=; b=jCdSBDUHO2tD 1V9ckNsj/3NZg+RdyCOQG4WCWgOYVNsOZXSMRb0lPXNjvISE83nivjCmgvEwvdAtaIqJddwJ9H9Hm SBZ6ERcLruROKrPKcGIBf5UMqzDBkk36u4cJQAstH2Y5KBZEO04oGzd46VW2inepm6/grptOsqRit vzJspN/KNnq7jnaJvQaSwoMv/4jVET7mAPl6SUDLtk+7Qm9LkO027HFfvc/+UCbrVLMpJr3UDpJCb jS3s8xahRqM/HaJggPg4qKMx3AdHrOokawjs39aHk9WrzfAqWNuaq4WoLw5ZUXaWct+OCOtkkixEP RDFAvaYiqcw5rp5hOt2Q9g==; In-Reply-To: <202403081423.428ENSpk162347@zeus.jtan.com> (chohag@jtan.com) 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:281234 Archived-At: > From: chohag@jtan.com > cc: chohag@jtan.com, 69598@debbugs.gnu.org > Comments: In-reply-to Eli Zaretskii > message dated "Fri, 08 Mar 2024 14:22:52 +0200." > Date: Fri, 08 Mar 2024 14:23:26 +0000 > > > > If we're at the point where the terminal's name matters one jot, > > > that is to say when the value of $TERM is used for _anything_ other > > > than selecting a terminfo entry, that is a bug. > > > > It is not necessarily a bug. Emacs needs to be able to convert > > It's a problem inasmuch as it is a violation of the terminfo protocol > and takes a sharp turn into non-standards territory. Perhaps bug > is not the best term. It's certainly a red flag. We only do that for handling the colors, and I'm not sure I can see how terminfo can help us here. terminfo knows how many colors a terminal supports and which escape sequences to use for that, but it doesn't know which colors will be produced, in terms of the RGB triplets. So Emacs needs something else to support colors on text terminals, and that something comes from the lisp/term/ files. Those files also set up Emacs for various non-standard function keys produced by the terminal, and support other features, like copy/paste etc. So these files are not a bug, they are the foundation of several important features in Emacs. > > X-style color names to escape sequences it should send to the terminal > > to produce a similar color. That conversion is specific to the > > terminal, so Emacs relies on the name of the terminal to set up the > > conversion. > > Hmm. If only there was some sort of database that described > terminal-specific capabilities and features and how to use them. > It could also ensure the programs were portable, even to terminals > that haven't been created yet! Yes. But AFAIK there's no such database, so Emacs must use its own database. > > This is not enough. You need also to change this line at the end of > > notworking.el: > > > > (provide 'term/xterm) > > > > to say > > > > (provide 'term/notworking) > > > > Sorry I didn't mention this before. > > No worries. It still makes no difference though unfortunately. > > But to be thorough I changed all instances of xterm in that > notworking.el to notworking and that did work. After a few minutes > I isolated the change to renaming terminal-init-xterm to > terminal-init-notworking. In fact that's the only change that needs > to be made: This diff is sufficient: > > --- lisp/term/xterm.el Sat Jan 6 12:56:30 2024 > +++ lisp/term/notworking.el Fri Mar 8 14:00:28 2024 > @@ -913,7 +913,7 @@ > ;; We likewise unconditionally enable support for focus tracking. > (xterm--init-focus-tracking)) > > -(defun terminal-init-xterm () > +(defun terminal-init-notworking () > "Terminal initialization function for xterm." > (unwind-protect > (progn > > I was actually a little surprised when I changed the provide line > back to 'term/xterm and it continued to work but this agrees with > lisp/term/README. So you now agree with me that a terminal file in lisp/term is needed for this situation? Or are there issues that are still unaccounted for, as far as color support is concerned? > That explains why the workaround of using a terminal name beginning > with xterm- works. It doesn't explain why that is necessary and > using setb24/setf24, the RGB capability and/or COLORTERM=truecolor > is insufficient (ie. it doesn't explain why the terminal name > _matters_). I hope what I wrote above explains that. If you read the code in xterm.el, I think you will understand it. The other part of the color-related support is in lisp/term/tty-colors.el, btw.