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 09:11:03 +0200 Message-ID: <86jzmd19mg.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29850"; 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 08:12:02 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 1riUOg-0007c1-BN for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Mar 2024 08:12:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1riUOC-0000nF-4Z; Fri, 08 Mar 2024 02:11:32 -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 1riUOA-0000mf-Vx for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 02:11: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 1riUOA-0001PQ-J7 for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 02:11:30 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1riUOg-0005uo-EU for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 02:12:02 -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 07:12:02 +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.170988191422725 (code B ref 69598); Fri, 08 Mar 2024 07:12:02 +0000 Original-Received: (at 69598) by debbugs.gnu.org; 8 Mar 2024 07:11:54 +0000 Original-Received: from localhost ([127.0.0.1]:56185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riUOY-0005uS-37 for submit@debbugs.gnu.org; Fri, 08 Mar 2024 02:11:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riUOV-0005uE-JO for 69598@debbugs.gnu.org; Fri, 08 Mar 2024 02:11:52 -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 1riUNt-0001Eg-2D; Fri, 08 Mar 2024 02:11:13 -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=TPuqUu4VCAwJ55JsgvYn/q87t6H4t328uv/oe3ZZChM=; b=kq6jdpJE2Vzn kQcfdtfwQK88z9C6V7Vtvipil4BqQpGc35jFsrWSc9gGAvjUDtMijoecIfuF9drGnIk6GsJ6Bgi3E iXoanB5syQC0xs0JTy0F8Yzb0Zdihc2WaqrStR2iA+GbFH6GYE4sJDA1HyRY9+qoEOh0FwGDOQJ4k qU5fY5F0acP414bB6q39RVCR+8SiHjqK1ZBA/b7whCD6t2ywgKr3sNLQYkHhJIOu6hmS1AgRvSqcU VTgnVl6Xhqqm+nnds/7MX47rZC27pXnogGhZWmWBwzlk6/neOrOxXkkmTEdFpXzZsKWrdR9LWvCRd HrSJPDk5yzHmQI6tUd7tLg==; In-Reply-To: <202403072145.427LjkS8393330@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:281205 Archived-At: > 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 > > I have (eventually, see below) followed this sequence of steps: > > $ cd ~/src/emacs-29.2 > $ ./configure > $ gmake > > launch xterm, and then within it: > > $ rm -fr ~/.terminfo > $ echo 'notworking|Non-working clone,use=xterm-direct,' > new.info > $ echo 'xterm-working|Working clone,use=xterm-direct,' >> new.info > $ tic new.info > > # pre-patch compiled binary: > > $ export TERM=xterm-direct > $ ~/src/emacs-29.2/src/emacs -nw > $ M-x list-colors-display # confirm 256 named colours > $ export TERM=notworking > $ ~/src/emacs-29.2/src/emacs -nw > $ M-x list-colors-display # confirm only 8 colours > $ export TERM=xterm-working > $ emacs -nw # system xterm > $ M-x list-colors-display # confirm 256 named colours > > # patch: > --- src/term.c~ Sat Jan 6 12:56:31 2024 > +++ src/term.c Thu Mar 7 20:56:36 2024 > @@ -4235,6 +4235,15 @@ > tty->TN_no_color_video = 0; > } > > + { > + int bug = open("/tmp/debug", O_WRONLY | O_CREAT); > + dprintf(bug, "pair: %s\n", tty->TS_orig_pair); > + dprintf(bug, "bg: %s\n", tty->TS_set_background); > + dprintf(bug, "fg: %s\n", tty->TS_set_foreground); > + dprintf(bug, "max: %zu\n", tty->TN_max_colors); > + close(bug); > + } > + > tty_default_color_capabilities (tty, 1); > > MagicWrap (tty) = tgetflag ("xn"); > > $ gmake -C ~/src/emacs-29.2 > $ export TERM=xterm-direct > $ ~/src/emacs-29.2/src/emacs -nw > $ M-x list-colors-display $ # confirm 256 named colours > $ doas cat /tmp/debug # doas because umask 0 > pair: > bg: 1%{8}%<%t4%p1%d%e48:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m > fg: 1%{8}%<%t3%p1%d%e38:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m > max: 16777216 > $ rm -f /tmp/debug # just in case > $ export TERM=notworking > $ ~/src/emacs-29.2/src/emacs -nw > $ M-x list-colors-display # confirm only 8 colours > $ doas cat /tmp/debug > pair: > bg: 1%{8}%<%t4%p1%d%e48:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m > fg: 1%{8}%<%t3%p1%d%e38:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m > max: 16777216 > $ rm -f /tmp/debug > $ export TERM=xterm-working > $ ~/src/emacs-29.2/src/emacs -nw > $ M-x list-colors-display # confirm 256 named colours > $ doas cat /tmp/debug > pair: > bg: 1%{8}%<%t4%p1%d%e48:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m > fg: 1%{8}%<%t3%p1%d%e38:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%d%;m > max: 16777216 > 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? 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=notworking 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=NAME. > 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'. > > In fact before getting the patch to this stage I included the print > statements within the block you suggested but of course this was > not reached because of op not being detected. > > It didn't make any sense to me why tgetstr would return an empty > string in that instance. address where tgetstr gets its data from > is another name for tty->termcap_strings_buffer so changing the > print statement to print that and setting $TERM to xterm-direct > reveals: > > $ doas hexdump -C /tmp/debug > 00000000 60 60 60 1b 5b 4c 27 27 27 0a |```.[L'''.| > 0000000a 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?