I'm responding to all the messages so far in one email to keep the volume
down:

> Support for bidi reordering seems to be missing.

This is a very good suggestion. Added.

> The "emacs" column seems to be empty, is that on purpose?

The purpose of this thread is to add some checkmarks there.

> I think more that "which capabilities should be reported", I'd first
focus on a standard way to enable/disable and query (both presence and
activation status) capabilities.
> E.g. it should be safe to enable or disable *any* capability, supported
or not.

Creating a standard set of extensions to DECSET and DECRQM is interesting,
and something I'd like to explore, but it's orthogonal to the goals of this
project. I really want to stay focused because there's already been a year
of bikeshedding leading up to this point. I'm laser focused on shipping
something useful to start mitigating the brokenness of $TERM.

> From where I stand, environment variables are the last resort since they
may get lost along the way or may be inherited unwittingly from elsewhere.

Yeah, they're not ideal. It's a useful optimization for something like a
shell script. I expect a full fledged program like emacs would use a
control sequence requesting a feature report. It's slower than an
environment variable but at least it's accurate.

> I wrote about this issue a little while ago:
https://www.facebook.com/notes/daniel-colascione/term-is-terminally-broken/10154219967001102/

> Using an environment variable might be fine so long as it's *one*
environment variable, minimizing the pain of transition. But there are
zillions of scripts and daemons out there that special-case TERM. (For
example, sudo often puts TERM on an environment variable preservation
whitelist.) It'd probably be easier to make a new special TERM variable
that means "I support introspection and also speak xtermeese".

terminfo is useful as a baseline, but it's impossible to propagate changes
in a timely manner. The goal of my project is to fill in the gaps that
terminfo leaves, so you can adopt this new info gradually to get wins where
it's available. I expect it would be one variable. Something like
TERM_FEATURES="xxx" where xxx is a compact encoding of the feature flags.
Advertising that you support introspection is a chicken-and-egg problem. I
expect the best option is to request a feature report and then send CSI c
(or some other reporting control sequence), and see if you get one report
back or two.


On Fri, May 8, 2020 at 11:29 AM Daniel Colascione <dancol@dancol.org> wrote:

> On 5/8/20 12:34 AM, George Nachman wrote:
> > Some terminal emulator authors (VTE, xterm, tmux, mintty, libvterm,
> > iTerm2, and others) are discussing building a new mechanism for
> > reporting capabilities. For context:
> > https://github.com/mintty/mintty/issues/881
>
> Hallelujah.
>
> > My goal is to collect desires from developers of popular applications.
> > What capabilities do you wish you could discover about terminals that
> > you don't already get from terminfo?
> >
> > For example, being able to detect 24-bit color support, available cursor
> > styles, bracketed paste support, and mouse reporting modes are the kinds
> > of capabilities that would be included.
>
> I wrote about this issue a little while ago:
>
> https://www.facebook.com/notes/daniel-colascione/term-is-terminally-broken/10154219967001102/
>
> Using an environment variable might be fine so long as it's *one*
> environment variable, minimizing the pain of transition. But there are
> zillions of scripts and daemons out there that special-case TERM. (For
> example, sudo often puts TERM on an environment variable preservation
> whitelist.) It'd probably be easier to make a new special TERM variable
> that means "I support introspection and also speak xtermeese".
>
> > They would likely be exposed
> > through a combination of a new environment variable and a
> > to-be-determined control sequence that reports them.
>
> Kitty's mechanism for explicitly setting character-cell properties would
> be great to discover too --- it's a much better alternative to BCE.
>