all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: chohag--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 69598@debbugs.gnu.org, chohag@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	[thread overview]
Message-ID: <202403082113.428LDTAX391981@zeus.jtan.com> (raw)
In-Reply-To: <86edckzeom.fsf@gnu.org>

Eli Zaretskii writes:
> > 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 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






  reply	other threads:[~2024-03-08 21:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 23:01 bug#69598: 29.2; colour support based on $TERM value not terminfo database chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07  6:47 ` Eli Zaretskii
2024-03-07 17:32   ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 17:47     ` Eli Zaretskii
2024-03-07 18:31       ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 19:26         ` Eli Zaretskii
2024-03-07 19:59           ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 20:10             ` Eli Zaretskii
2024-03-07 21:45               ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 21:50                 ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08  7:11                 ` Eli Zaretskii
2024-03-08 11:36                   ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 12:22                     ` Eli Zaretskii
2024-03-08 14:23                       ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 15:09                         ` Eli Zaretskii
2024-03-08 18:52                           ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 19:50                             ` Eli Zaretskii
2024-03-08 21:13                               ` chohag--- via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-03-09  7:18                                 ` Eli Zaretskii
2024-03-21  8:33                                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202403082113.428LDTAX391981@zeus.jtan.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=69598@debbugs.gnu.org \
    --cc=chohag@jtan.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.