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 11:36:18 +0000 Message-ID: <202403081136.428BaKSG077496@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> Reply-To: chohag@jtan.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24799"; 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:05 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 1rieCS-0006Ha-Po for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Mar 2024 18:40:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rieBy-0007mJ-Lj; 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 1rieBv-0007ky-UH 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 1rieBv-0008TF-Lt for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 12:39:31 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rieCR-0006tQ-Pa for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 12:40:03 -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: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.170991954326362 (code B ref 69598); Fri, 08 Mar 2024 17:40:03 +0000 Original-Received: (at 69598) by debbugs.gnu.org; 8 Mar 2024 17:39:03 +0000 Original-Received: from localhost ([127.0.0.1]:59454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rieBR-0006qf-CG for submit@debbugs.gnu.org; Fri, 08 Mar 2024 12:39:03 -0500 Original-Received: from 237-he.filtered.junkemailfilter.com ([184.105.182.237]:35206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riYXJ-0003ZI-Ff for 69598@debbugs.gnu.org; Fri, 08 Mar 2024 06:37:22 -0500 Original-Received: from [184.105.182.254] (port=37018 helo=mailout.jtan.com) (helo=mailout.jtan.com) by outscan.junkemailfilter.com with esmtp (JEF) id 1riYWh-0004ZV-Rh (on interface=184.105.182.200); Fri, 08 Mar 2024 03:36:35 -0800 Original-Received: from mail.jtan.com (localhost [127.0.0.1]) by mailout.jtan.com (Postfix) with ESMTP id 0267CF816D9; Fri, 8 Mar 2024 11:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=jtan.com; s=jtan8; t=1709897782; bh=eepDw0f6R4TeMHG6GraMCdNhL0LA9ytI3RQyaqjSuI4=; h=From:To:cc:Subject:References:Date:From:Reply-To:To:Date:Subject; b=bRW83n0dYzhultYGzPqNobnf0RFsxUu3aDEoFYdFr3bR6nNxH97/P/nT8+27e+ZOz n28nCPbMJUBKy5Hi9iclQpPh9/8jnGkfan+4TQwngDcVpE/0lBiRUCsd3S8FJTT1A0 XmTjDHvJsmLnFKcsLDcl6sSMORNJ+8sxshS/xesdLtG2cs4aqqxwMd2NmoxrLZPouT BCYZ4c8GjKt3TzDcGJ9Gi0vAw1ELH73DBMk6/LqGz/uqjoUbsHZ5f7pW63I/Gecz+h w3Tls5q/fYB7mrS2P2Z7DJwiwopaMSeHdknV4Dm2gvDJmJBgFCCBE8dtnC0WPdFOST DEZt+rVBlm+OA== Original-Received: from zeus.jtan.com (localhost [127.0.0.1]) by mail.jtan.com with ESMTPS id 428BaKvQ077497 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Mar 2024 11:36:21 GMT Original-Received: (from chohag@localhost) by zeus.jtan.com (8.15.2/8.14.4/Submit) id 428BaKSG077496; Fri, 8 Mar 2024 11:36:20 GMT In-reply-to: <86jzmd19mg.fsf@gnu.org> Comments: In-reply-to Eli Zaretskii message dated "Fri, 08 Mar 2024 09:11:03 +0200." Content-ID: <64916.1709897778.1@llama.datum> X-Spamfilter-host: outscan.junkemailfilter.com - http://www.junkemailfilter.com X-Key-ID: ZWxpekBnbnUub3JnIGNob2hhZ0B6ZXVzLmp0YW4uY29tIDIwMjQtMDMtMDggMDM6MzY6MzUuODc0IDFyaVlXaC0wMDA0WlYtUmg= X-Content-flags: accept agree apparent appear available black comparing confirm confirmed dashes date dated direct email-adr excited follows here ident identical immediately important info infocmp information interested invalid invoke message messages number-text option order please point pointed problem re register reminded reply reported requesting satisfied start term terminal terminfo thanks time-ref working 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:281254 Archived-At: Eli Zaretskii writes: > > From: chohag@jtan.com > > cc: chohag@jtan.com, 69598@debbugs.gnu.org > > Comments: In-reply-to Eli Zaretskii > > message dated "Thu, 07 Mar 2024 22:10:30 +0200." > > Date: Thu, 07 Mar 2024 21:45:44 +0000 > > 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 =3D tgetnum ("Co")' and then set again when the RGB or other direct-colour capability is detected. Unfortunately the information from terminfo is sometimes ignored. > I think the problem is that if the terminal's name doesn't begin with > "xterm", Emacs does not load lisp/term/xterm.el, which defines the > colors that will be available. So please copy lisp/term/xterm.el to a > file named lisp/term/notworking.el, and then start Emacs with > TERM=3Dnotworking and see if that solves the problem. That is, arrange > for a lisp/term/NAME.el file to be a copy of xterm.el when you invoke > Emacs with TERM=3DNAME. 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. I don't know how emacs finds files when it's not installed so I will be thorough: $ cd ~/src/emacs-29.2 $ cp lisp/term/xterm.el lisp/term/notworking.el $ gmake $ ls -l lisp/term/{xterm,notworking}* -rw-r--r-- 1 mking mking 46048 Mar 8 10:46 lisp/term/notworkin= g.el -rw-r--r-- 1 mking mking 32368 Mar 8 10:46 lisp/term/notworkin= g.elc -rw-r--r-- 1 mking mking 46048 Jan 6 12:56 lisp/term/xterm.el -rw-r--r-- 1 mking mking 32368 Jan 18 10:06 lisp/term/xterm.elc $ infocmp -x notworking xterm-direct # to confirm they're ident= ical comparing notworking to xterm-direct. comparing booleans. comparing numbers. comparing strings. $ export TERM=3Dnotworking $ ./src/emacs -nw # confirm 8 colours $ export TERM=3Dxterm-direct $ ./src/emacs -nw # confirm 256 named colour= s While I was setting up this test I'd forgotten that I changed the value in each of the three assignments to TN_max_colors in order to confirm which condition inside the TERMINFO block was satisfied. Before correcting that, running with TERM=3Dnotworking reported 8 colours but with TERM=3Dxterm-direct reported 16 (the extra 8 are all black) and said in *Messages*: xterm-register-default-colors: Unsupported number of xterm colors (16777214). The value ending in 4 pointed to the tigetflag("RGB") block which reminded me of the -x option to tic telling it to accept non-standard capabilities (of which RGB is one) and I thought perhaps the option was also necessary when creating an entry which uses an entry which has non-standard capabilities. It turns out that it is and that notworking was lacking the extra capabilities. So I got excited that maybe I'd found the problem and it was in fact bad terminfo data. I did the whole round of tests again but this time using "tic -x new.info" instead of plain tic (confirmed with infocmp -x that the extended capabilities exist in the new terminfo entries notworking and xterm-working). The result was identical. 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=3Dnotworking an invalid TN_max_colors is ignored). Creating the file lisp/term/notworking.el had no apparent effect. That's it. Nothing important follows. > > Notably TS_orig_pair is printed here as an empty string in all cases > > (NULL would print as "(null)"? and there there are no extra spaces), > > created by requesting the op capability which *is* defined in > > xterm-direct. > > = > > $ infocmp dumb xterm-direct | grep op: = > > op: NULL, '\E[39;49m'. > > I don't think I see why TS_orig_pair's value is relevant to the issue > at hand. Can you explain why you are interested in it? Immediately prior to the TERMINFO block is this code: /* SVr4/ANSI color support. If "op" isn't available, don't supp= ort color because we can't switch back to the default foreground = and background. */ tty->TS_orig_pair =3D tgetstr ("op", address); if (tty->TS_orig_pair) { tty->TS_set_foreground =3D tgetstr ("AF", address); tty->TS_set_background =3D tgetstr ("AB", address); if (!tty->TS_set_foreground) { /* SVr4. */ tty->TS_set_foreground =3D tgetstr ("Sf", address); tty->TS_set_background =3D tgetstr ("Sb", address); } tty->TN_max_colors =3D tgetnum ("Co"); #ifdef TERMINFO { ... } #endif When I originally patched term.c (I've had enough of using one terminal to debug another terminal that is running its own terminal) I included the print statements at the end of the TERMINFO block and the debug file did not get created. I moved it down to above the next '}' line which appears to correspond to the test of tty->TS_orig_pair to no avail (the combination of C, CPP and indentation is hard to follow) then I moved it out of that block and began the test which got the results I sent last night. Probing it again with coffee it appears that TS_orig_pair is given a value and the block is entered so I expect I misread something when writing the patch. That reveals a misunderstanding, again because I assumed a cat would be enough. The pair line (printing tty->TS_orig_pair) does in fact have a value: 1b 5b 33 39 3b 34 39 6d which is the correct SGR control and would obviously not have an appearance when sent to a terminal. It is in the debug file. Focusing on tty->termcap_strings_buffer appears to be another red herring. I was trying to figure out where tgetstr is getting its data from and address n=C3=A9e area n=C3=A9e tty->termcap_strings_buffer w= as the obvious candidate. Cheers, Matthew