bug#69598: 29.2; colour support based on $TERM value not terminfo database

[Eli Zaretskii <eliz@gnu.org>]

> From: chohag@jtan.com
> cc: chohag@jtan.com, 69598@debbugs.gnu.org
> Comments: In-reply-to Eli Zaretskii <eliz@gnu.org>
>    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.