GNU bug report logs - #69598
29.2; colour support based on $TERM value not terminfo database

Previous Next

Full log

View this message in rfc822 format

From: chohag <at> jtan.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69598 <at> debbugs.gnu.org, chohag <at> jtan.com
Subject: bug#69598: 29.2; colour support based on $TERM value not terminfo database
Date: Fri, 08 Mar 2024 21:13:27 +0000

Eli Zaretskii writes:
> > From: chohag <at> jtan.com
> > cc: chohag <at> jtan.com, 69598 <at> debbugs.gnu.org
> > Comments: In-reply-to Eli Zaretskii <eliz <at> gnu.org>
> >    message dated "Fri, 08 Mar 2024 17:09:51 +0200."
> > Date: Fri, 08 Mar 2024 18:52:28 +0000
> > 
> > > 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.
>
> In that case, we will have to agree to disagree, sorry.

I don't, sorry.

> > 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.
>
> Support for colors beyond the basic 8 is very specific to terminals.

Hardware terminals which could not hope to display anything close
to individual full colour rendition for the background and foreground
of each character cell, without exhorbitant cost, did have myriad
ways of expressing their limited colour support, true, back when
such things were in the process of being invented, but out of all
the software terminal emulators and programs since which claim full
colour support, pretty much everything has followed the conventions
laid down by xterm and/or VTE which follow or try to follow ECMA-48,
T.416 and related formal and de-facto standards, such as describing
their capabilities with termcap (1978) and/or terminfo (1981).

> Emacs solves this problem by relying on the name of the terminal.  So

Everything except, apparently, Emacs.

> any new terminal has to abide by this protocol.  That's how this stuff
> works in Emacs.

That's what standards are for. Formal standards are those published
by some organisation, de-facto standards are the conventions followed
by a majority. Emacs' behaviour here is neither.

I should be clear that I'm not trying to get something fixed --- I
don't have a problem here. I can get along just fine but in my
travels I discovered that emacs did not work as I expected and, on
investigation, as it described itself and so I thought that GNU
would like know that their flagship product and/or its documentation
was deficient.

I have provided more information at your request which I hope you
find useful but I have no need or desire to pursue this matter.

Matthew

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.