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 18:52:28 +0000 Message-ID: <202403081852.428IqU5m307520@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> <202403081423.428ENSpk162347@zeus.jtan.com> <86sf10zrnk.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="12453"; 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 19:54:48 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 1rifMm-00030i-7t for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Mar 2024 19:54:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rifMU-0003eJ-OW; Fri, 08 Mar 2024 13:54:30 -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 1rifMT-0003e8-Sn for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 13:54:29 -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 1rifMT-00040d-Kk for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 13:54:29 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rifMz-0000QU-ON for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 13:55:01 -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 18:55:01 +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.17099241001626 (code B ref 69598); Fri, 08 Mar 2024 18:55:01 +0000 Original-Received: (at 69598) by debbugs.gnu.org; 8 Mar 2024 18:55:00 +0000 Original-Received: from localhost ([127.0.0.1]:59573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rifMx-0000Q8-LU for submit@debbugs.gnu.org; Fri, 08 Mar 2024 13:55:00 -0500 Original-Received: from 236-he.filtered.junkemailfilter.com ([184.105.182.236]:35871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rifLM-0000Nm-CA for 69598@debbugs.gnu.org; Fri, 08 Mar 2024 13:53:22 -0500 Original-Received: from [184.105.182.254] (port=58476 helo=mailout.jtan.com) (helo=mailout.jtan.com) by outscan.junkemailfilter.com with esmtp (JEF) id 1rifKk-0005Dj-C6 (on interface=184.105.182.200); Fri, 08 Mar 2024 10:52:42 -0800 Original-Received: from mail.jtan.com (localhost [127.0.0.1]) by mailout.jtan.com (Postfix) with ESMTP id 826A4F819F1; Fri, 8 Mar 2024 18:52:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=jtan.com; s=jtan8; t=1709923951; bh=aq/kr//lHjaKYx2bEi5qlr+L7hmlGw6/2RMd8PkqYsA=; h=From:To:cc:Subject:References:Date:From:Reply-To:To:Date:Subject; b=aneHVU0+oU2Xfmk65Rg3u+EcyUvuatTlyqX7RZYEct3MOKEWcUdRUnMJcqdEo8RDU IqnDjP+7rTrBpxnpRyw4AF6v+Yoox5DUgqPh8hdt5ojp9xXY98eWLgehw2B55YisCC h5skfmSRcRU8Ma+K1YKKjGjUKKxj32kDNjhXSLFccBIzZ6J5MKD8/AakW6+/2XoXrN 5udxkL/3geHlbbVzOVtsu8v51TySMe+1vpFvjKqrMZQ2X13vzK7thptX36DKFLH2eU qhg0pvTYIbTwz9urGYQT9b/oxKFG1CXtXFs5mTqmoxJz6xuJTZCtOOg8lWkI1TpUjM LkKK8MEBD9/Zw== Original-Received: from zeus.jtan.com (localhost [127.0.0.1]) by mail.jtan.com with ESMTPS id 428IqUrL307521 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Mar 2024 18:52:31 GMT Original-Received: (from chohag@localhost) by zeus.jtan.com (8.15.2/8.14.4/Submit) id 428IqU5m307520; Fri, 8 Mar 2024 18:52:30 GMT In-reply-to: <86sf10zrnk.fsf@gnu.org> Comments: In-reply-to Eli Zaretskii message dated "Fri, 08 Mar 2024 17:09:51 +0200." Content-ID: <12613.1709923948.1@llama.datum> X-Spamfilter-host: outscan.junkemailfilter.com - http://www.junkemailfilter.com X-Key-ID: ZWxpekBnbnUub3JnIGNob2hhZ0B6ZXVzLmp0YW4uY29tIDIwMjQtMDMtMDggMTA6NTI6NDIuNTM0IDFyaWZLay0wMDA1RGotQzY= X-Content-flags: agree appearance applications best certain certainly concerned custom date dated developments direct email-adr esire follow here https implies important link message number-text order point prefix problem produce produced programs protocol qualifications re ready record reply software special term terminal terminals terminfo terms time-ref transform web X-Domain-list: jtan.com gnu.org X-Outscan: http://www.junkemailfilter.com X-Mailman-Approved-At: Fri, 08 Mar 2024 13:54:58 -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:281261 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 "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 Terminfo doesn't ``know'' what a terminal supports. Terminfo is the database and routines to look up capabality values. It's the applications which use terminfo that ``know'' what those capabilities do and, of course, many of them have a conventional use as described in terminfo(5). In order to describe capabilities of terminals which hadn't been made in 1980 it can be expanded with new capabilities. For example setb24 and setf24 are terminfo extensions which as near as I can tell originated in emacs to do exactly what you describe. https://www.gnu.org/software/emacs/manual/html_node/efaq/Colors-on-a-TTY.html mentions setb24 and setf24. In fact it's the only page on the web that I can find (apart those linking to it) with any record of these controls: Emacs 26.1 and later support direct color mode in terminals. If Emacs finds Terminfo capabilities `setb24' and `setf24', 24-bit direct color mode is used. The capability strings are expected to take one 24-bit pixel value as argument and transform the pixel to a string that can be used to send 24-bit colors to the terminal. Standard terminal definitions don't support these capabilities and therefore custom definition is needed. setb24=\E[48\:2\:\:%p1%{65536}%/%d\:%p1%{256}%/%{255}%&\ %d\:%p1%{255}%&%dm, setf24=\E[38\:2\:\:%p1%{65536}%/%d\:%p1%{256}%/%{255}%&\ %d\:%p1%{255}%&%dm, ``24-bit direct color mode is use'' with no further qualifications. It doesn't say that emacs also needs to have special knowledge about the terminal's model. The page continues with examples for further developments but in every case implies or outright says that certain capabilities are the only requirement, not specific models. > 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. Their overriding what terminfo tells it is the buggy part. Terminfo says ``terminal foo has RGB or setf24 and setb24 capabilities and supports 16M colours'' but emacs disagrees. Incidentally, both of the examples you gave are already supported in some fashion by terminfo capabilities, for example: The kNNN capabilities map non-standard keys. bracketed+paste|xterm bracketed paste, BD=\E[?2004l, BE=\E[?2004h, PE=\E[201~, PS=\E[200~, > > > 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. I'm sorry, I was trying to use humour to point out that terminfo is that database. > 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? I don't agree. A new lisp/term file achieved the desired result, or rather the appearance of it, but for all of the wrong reasons: because the terminal lied about what it was. Looking at it another way if a user uses one of the terminals emacs supports but with certain features enabled or disabled by a custom terminfo entry there's nothing to say that the name of that entry has to follow any particular convention. A site prefix is a well established naming scheme so something like mycompany-footerm does not seem like an unreasonable name and nothing formally or informally in terminfo or termcap, or in emacs' documentation for that matter, suggests that it wouldn't work. Indeed I'm quite surprised to find this behaviour: emacs, running in xterm and informed it is running on a terminal identical to xterm, does not act the same as it does when that description comes under the *label* xterm. That's like the name of a variable influencing its contents. In short, if emacs only supports colour (or any other feature) on specific terminals it knows about in advance, it should say so and not imply that a terminfo or termcap capability is sufficient. As it stands this paragraph: If you think that your terminal supports colors, but Emacs won't use them, check the termcap entry for your display type for color-related capabilities. ... should be amended to say ``check if your terminal or emulator is one of these supported models: '' but couldn't emacs believe and use what terminfo has told it, otherwise why did it ask? Matthew