What capabilities do you wish terminal emulators would report?

What capabilities do you wish terminal emulators would report?

[George Nachman]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

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

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. They would likely be exposed through a
combination of a new environment variable and a to-be-determined control
sequence that reports them.

The results of this survey are being collected here:
https://docs.google.com/spreadsheets/d/1H4OK8z98ptySnAPjlej56lrL6b0S1j6okwp7KLRTDBQ/edit#gid=0
If you prefer not to use Google Docs, I have a PDF of its current contents
here: https://iterm2.com/misc/TerminalFeaturesCandidates1.pdf

Thanks in advance for your time, and apologies if this is the wrong forum
for this query—please redirect me if so!

-George

[-- Attachment #2: Type: text/html, Size: 1451 bytes --]

Re: What capabilities do you wish terminal emulators would report?

[Eli Zaretskii]

> From: George Nachman <gnachman@llamas.org>
> Date: Fri, 8 May 2020 00:34:27 -0700
> 
> Thanks in advance for your time, and apologies if this is the wrong forum for this query—please redirect me
> if so!

This is the right forum, thanks.

Re: What capabilities do you wish terminal emulators would report?

[Eli Zaretskii]

> From: George Nachman <gnachman@llamas.org>
> Date: Fri, 8 May 2020 00:34:27 -0700
> 
> 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
> 
> 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?

Support for bidi reordering seems to be missing.

> The results of this survey are being collected here:
> https://docs.google.com/spreadsheets/d/1H4OK8z98ptySnAPjlej56lrL6b0S1j6okwp7KLRTDBQ/edit#gid=0
> If you prefer not to use Google Docs, I have a PDF of its current contents here:
> https://iterm2.com/misc/TerminalFeaturesCandidates1.pdf

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

Re: What capabilities do you wish terminal emulators would report?

[Stefan Monnier]

> 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?

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.

> They would likely be exposed through a combination of a new
> environment variable and a to-be-determined control sequence that
> reports them.

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.


        Stefan

Re: What capabilities do you wish terminal emulators would report?

[Daniel Colascione]

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.

Re: What capabilities do you wish terminal emulators would report?

[George Nachman]

[-- Attachment #1: Type: text/plain, Size: 4119 bytes --]

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.
>

[-- Attachment #2: Type: text/html, Size: 5566 bytes --]

Re: What capabilities do you wish terminal emulators would report?

[Eli Zaretskii]

> From: George Nachman <gnachman@llamas.org>
> Date: Fri, 8 May 2020 13:51:39 -0700
> Cc: emacs-devel@gnu.org
> 
> > The "emacs" column seems to be empty, is that on purpose?
> 
> The purpose of this thread is to add some checkmarks there.

How does one go about doing that?

Re: What capabilities do you wish terminal emulators would report?

[George Nachman]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

Please respond on this thread and I'll update the spreadsheet, or else add
a comment to the spreadsheet. I don't want to open up write access to the
world because that would be total chaos.

On Fri, May 8, 2020 at 11:09 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: George Nachman <gnachman@llamas.org>
> > Date: Fri, 8 May 2020 13:51:39 -0700
> > Cc: emacs-devel@gnu.org
> >
> > > The "emacs" column seems to be empty, is that on purpose?
> >
> > The purpose of this thread is to add some checkmarks there.
>
> How does one go about doing that?
>

[-- Attachment #2: Type: text/html, Size: 1015 bytes --]

Re: What capabilities do you wish terminal emulators would report?

[Eli Zaretskii]

> From: George Nachman <gnachman@llamas.org>
> Date: Sat, 9 May 2020 12:41:45 -0700
> Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
> 
> Please respond on this thread and I'll update the spreadsheet, or else add a comment to the spreadsheet. I
> don't want to open up write access to the world because that would be total chaos.

Color capabilities: Emacs supports 24-bit colors on capable terminals.
OSC 52: I think Emacs supports that on capable terminals, but I'm
confused by the references to base-64 encoding there, so maybe I'm
wrong.
SGR mouse: Emacs has full support for the mouse.
UTF-8 support: Check.
AMBIGUOUS_FULLWIDTH: Not quite sure what this is about, but Emacs does
support fullwidth characters per East-Asian Width defined by the
latest Unicode Standard.
Unicode version: Emacs supports the latest one.
RTL/BIDI: Emacs supports bidirectional editing per UAX#9 of the latest
Unicode Standard version.
Title setting: Supported.
Bracketed paste: Supported.
Focus reporting: Supported.