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.