From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chohag--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69598: 29.2; colour support based on $TERM value not terminfo database Date: Fri, 08 Mar 2024 14:23:26 +0000 Message-ID: <202403081423.428ENSpk162347@zeus.jtan.com> 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> Reply-To: chohag@jtan.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25663"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69598@debbugs.gnu.org, chohag@jtan.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 08 18:40:13 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 1rieCa-0006Ss-VF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Mar 2024 18:40:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rieBy-0007mB-Lu; Fri, 08 Mar 2024 12:39:34 -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 1rieBw-0007lJ-AZ for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 12:39:32 -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 1rieBw-0008TM-1t for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 12:39:32 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rieCS-0006tY-5P for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 12:40:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: chohag@jtan.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Mar 2024 17:40:04 +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.170991954926390 (code B ref 69598); Fri, 08 Mar 2024 17:40:04 +0000 Original-Received: (at 69598) by debbugs.gnu.org; 8 Mar 2024 17:39:09 +0000 Original-Received: from localhost ([127.0.0.1]:59461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rieBZ-0006rX-29 for submit@debbugs.gnu.org; Fri, 08 Mar 2024 12:39:09 -0500 Original-Received: from 239-he.filtered.junkemailfilter.com ([184.105.182.239]:59475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rib8q-0000BQ-4j for 69598@debbugs.gnu.org; Fri, 08 Mar 2024 09:24:12 -0500 Original-Received: from [184.105.182.254] (port=54674 helo=mailout.jtan.com) (helo=mailout.jtan.com) by outscan.junkemailfilter.com with esmtp (JEF) id 1rib8E-0000lw-62 (on interface=184.105.182.200); Fri, 08 Mar 2024 06:23:30 -0800 Original-Received: from mail.jtan.com (localhost [127.0.0.1]) by mailout.jtan.com (Postfix) with ESMTP id AD441F8177B; Fri, 8 Mar 2024 14:23:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=jtan.com; s=jtan8; t=1709907809; bh=rZbqWfPvVjuXgaxhAmIYk9Esh9pQr8CrpuixMfzDkhg=; h=From:To:cc:Subject:References:Date:From:Reply-To:To:Date:Subject; b=Sbess0ux2UStUlsxROEpHA2vMj722OSadQpqLGR6ZGZgUxXWCkwKGUTW2TvYiVhqL hyzhXqQdJycSpvg+8g5BgG1m1Y8FkKoIQ2fQil0Dd3EUvoVDmw55yWaxlUkVeMeHSO QyaKJ4pAm7ffgAAt2zqVl0EXh7xXOGUug7q74woGcUTc5vdLtvrLN0YMiKCMJWmvhy bAaN4Barn/eW6dmnbdGiTdLVp75TgB2p20qiBkOgHIJTBUQX9CbLteHb+n+dzV1Oog nE9oWF/+wybBzqNzZiGH472fRrg9r/bTi7ysdmoiW4v3J9ZMJAai6f3YnUQ4ObGvVB YSSR3Xj+UWzyw== Original-Received: from zeus.jtan.com (localhost [127.0.0.1]) by mail.jtan.com with ESMTPS id 428ENS8I162348 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Mar 2024 14:23:29 GMT Original-Received: (from chohag@localhost) by zeus.jtan.com (8.15.2/8.14.4/Submit) id 428ENSpk162347; Fri, 8 Mar 2024 14:23:28 GMT In-reply-to: <86zfv8zzdv.fsf@gnu.org> Comments: In-reply-to Eli Zaretskii message dated "Fri, 08 Mar 2024 14:22:52 +0200." Content-ID: <10888.1709907806.1@llama.datum> X-Spamfilter-host: outscan.junkemailfilter.com - http://www.junkemailfilter.com X-Key-ID: ZWxpekBnbnUub3JnIGNob2hhZ0B6ZXVzLmp0YW4uY29tIDIwMjQtMDMtMDggMDY6MjM6MzAuMjAyIDFyaWI4RS0wMDAwbHctNjI= X-Content-flags: actually agree agrees apparently appear best black certainly compiled complained complete confirmed dashes direct discards discussion down information invalid invisible messages night number-text point problem produce progn programs protect protocol provide re register reported start term terminal terminals terminfo thanks time-ref tracking understand understanding window work workaround working works X-Domain-list: jtan.com gnu.org X-Outscan: http://www.junkemailfilter.com X-Mailman-Approved-At: Fri, 08 Mar 2024 12:38:59 -0500 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:281255 Archived-At: Eli Zaretskii writes: > > > Thanks. These results AFAIU indicate that there's no problem with the > > > terminfo level: the number of colors known to term.c (printed as max:) > > > is the same no matter how you start Emacs. Do you agree with this > > > conclusion? > > > > That does appear to be the case. In fact the number of colours is > > set by 'tty->TN_max_colors = tgetnum ("Co")' and then set again > > when the RGB or other direct-colour capability is detected. > > That's correct, but why is that an issue? What I saw in your > debugging print-outs is that the value of tty->TN_max_colors was the It's not an issue, just a description of where the value comes from. > > Unfortunately the information from terminfo is sometimes ignored. > > Why "unfortunately", if the result is the correct number of colors? It's unfortunate that emacs (apparently) discards what it's told in favour of heuristics. Especially as the heuristics appear to draw the wrong conclusion. > > 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. > 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! > We could have a new feature whereby, if terminfo redirected to a > different entry, Emacs would load the lisp/term file of the redirected > entry. But that'd be a new feature that AFAIU never existed in Emacs. My understanding is that the inclusion by terminfo is invisible to programs which use it. Being xterm-specific leads you down the path of a term/xxx.el file for each terminal which has non-standard features that you wish to use. You are correct to note that this part of the discussion is academic until the fault is found. > 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. 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 didn't test Tc. I don't think it would make a difference. > > Before correcting that, running with TERM=notworking reported 8 > > colours but with TERM=xterm-direct reported 16 (the extra 8 are all > > black) and said in *Messages*: xterm-register-default-colors: > > Unsupported number of xterm colors (16777214). > > > > ... > > Sorry, I don't think I understand the above. In particular, I don't > see the value 16777214 anywhere in term.c. What did I miss? There were two things. First that even though the first time I ran the test last night my compiled test terminfo entries were incomplete, re-running the test with complete entries made no difference to the outcome of the test. Second and separately from any other tests, I had changed the three instances of 16777216 within the TERMINFO block to 16777213, 16777214 and 16777215 to see which path in that code was taken (tigetflag("RGB") in all cases). When I left the incorrect numbers in place, the *Messages* window complained that the number was invalid but only when TERM=xterm-direct or TERM=xterm-working. (And just confirmed that with a working notworking.el, TERM=notworking also complains about this problem) > > Summary: > > > > My generated terminfo files were wrong. I needed to use tic -x. > > > > That doesn't matter though because whether or not emacs detects > > "RGB", direct colour availability depends on the $TERM value beginning > > with "xterm-" (and, curiously, that TN_max_colors is valid --- if > > TERM=notworking an invalid TN_max_colors is ignored). > > Is that a fact or is it a conclusion from what you observed? If the > latter, I think we still have stuff to test, see above. This is a description of the symptoms I have observed. Matthew