From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: George Nachman Newsgroups: gmane.emacs.devel Subject: Re: What capabilities do you wish terminal emulators would report? Date: Fri, 8 May 2020 13:51:39 -0700 Message-ID: References: <68b67ab2-dddc-aa07-d946-6fb1b3f4f742@dancol.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009a0bca05a5292a18" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="8378"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 08 22:52:34 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jX9yz-00024D-Hl for ged-emacs-devel@m.gmane-mx.org; Fri, 08 May 2020 22:52:33 +0200 Original-Received: from localhost ([::1]:44338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jX9yy-0000uu-K6 for ged-emacs-devel@m.gmane-mx.org; Fri, 08 May 2020 16:52:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jX9yM-0000OB-4o for emacs-devel@gnu.org; Fri, 08 May 2020 16:51:54 -0400 Original-Received: from mail-oo1-xc41.google.com ([2607:f8b0:4864:20::c41]:35602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jX9yK-0003CM-5D for emacs-devel@gnu.org; Fri, 08 May 2020 16:51:53 -0400 Original-Received: by mail-oo1-xc41.google.com with SMTP id t12so626842oot.2 for ; Fri, 08 May 2020 13:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=llamas-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=REgnsC7pNg0Er43DplWCI3PZ/cjOF/FylwNAOyb9lsg=; b=SX5gCYbvx4UfcbqWWlMrM0CN96pStyhEto3MzByxxOQ118qlmy9rrxYRPiGt12qQP/ bZgQzBiLNNd/fMyjezQf+TnQPrlepOnHu3hcvMJg1w4cPnhntZy8JEybkW/7gOtWeeDP 2gfkJIWSjHT1AwtmQ/HnSpcOPjq9kgiHqcEyvtelYidTulP8s8gZhHe2R84GyfbuRPMv NPlqo7OHJ9SZi6rnA6qQMpssMRQMY1UnU7+YffMppiPN+QkDXqMVOt4B4spvQcRknORF 8QBqNXrtSAjVxKp+7IAeLtpfWq5QG/PYBlo7EV9AQ5S1H7sVDd9th+FfW4GwRwVhD3hI qkIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=REgnsC7pNg0Er43DplWCI3PZ/cjOF/FylwNAOyb9lsg=; b=oRHqydxCjzhRaaMyeiYMN09XgDx90FiuDup8lnp3bO+B2pw30ixhCBdws5OjZ4aGnG rLlLu4q0b+fcWtfboI8WgA4LPLcWRUidzL3ZnQSbdwrFM8+avsbW7jpVbsV8uRbu9rZg UIvXtuS/eKJiUVhAUwPcymc+QDOnOnT3hC8tvn6+jZf1iGa3iJUnC1VajwssUISTLd3q UvIYENAEOZOpQ3hPTNv80ger3j4WoBWgBYFGxDn49iKxNQ0Wg+/+CO2s6hb4ABsgEqHA 3DLDuqfgfmPHT5SL7bfohkSfFmqyWNqKiVtu1rVUhr9QQmY9RaAwMIdoAwtpdwtbGR6N Ns9Q== X-Gm-Message-State: AGi0PuYw5WkrhY4+7ZZSDAuEIUD3EgM3WUtnJ8VeTaMQ+tmpHymiubN8 aCDvCf10zjYhwvT96bXeLeqvkFjUVqq/0Iluqjk= X-Google-Smtp-Source: APiQypKrnstzpCPsm5rpB+vKvjLOFz+m81gpmybIvPRLmB+HUONVrlACEZpVILFzCOTeR9vdilMDRK6+IGGV9gfLNgk= X-Received: by 2002:a05:6820:164:: with SMTP id k4mr4380329ood.30.1588971110531; Fri, 08 May 2020 13:51:50 -0700 (PDT) In-Reply-To: <68b67ab2-dddc-aa07-d946-6fb1b3f4f742@dancol.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::c41; envelope-from=gnachman@gmail.com; helo=mail-oo1-xc41.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:249326 Archived-At: --0000000000009a0bca05a5292a18 Content-Type: text/plain; charset="UTF-8" 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 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. > --0000000000009a0bca05a5292a18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm responding to all the messages so far in one = email to keep the volume down:

> Support for bidi re= ordering seems to be missing.

This is a very good suggestion. Adde= d.

> The "emacs" column seems to be e= mpty, is that on purpose?

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

> I thi= nk more that "which capabilities should be reported", I'd fir= st focus on a standard way to enable/disable and query (both presence and a= ctivation status) capabilities.
> E.g. it should be safe to enable = or disable *any* capability, supported or not.
<= br>
Creating=C2=A0a standard set of extensions to DECSET and=C2= =A0DECRQM is interesting, and something I'd like to explore,=C2=A0but i= t's orthogonal to the goals of this project. I really want to stay focu= sed because there's already been a year of bikeshedding leading up to t= his point. I'm laser focused on shipping something useful to start miti= gating the brokenness of $TERM.

> From where I = stand, environment variables are the last resort since they
may get lo= st 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 f= eature report. It's slower than an environment variable but at least it= 's accurate.


> Us= ing an environment variable might be fine so long as it's *one* environ= ment variable, minimizing the pain of transition. But there are zillions of= scripts and daemons out there that special-case TERM. (For example, sudo o= ften 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 impossi= ble to propagate changes in a timely manner. The goal of my project is to f= ill in the gaps that terminfo leaves, so you can adopt this new info gradua= lly to get wins where it's available. I expect it would be one variable= . Something like TERM_FEATURES=3D"xxx" where xxx is a compact enc= oding 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, 2= 020 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 curs= or
> styles, bracketed paste support, and mouse reporting modes are the kin= ds
> 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/1015421= 9967001102/

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 woul= d
be great to discover too --- it's a much better alternative to BCE.
--0000000000009a0bca05a5292a18--