From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alex Hutcheson via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#54027: Wishlist: Support full CSI u specification for terminal input Date: Sun, 27 Feb 2022 13:21:20 -0500 Message-ID: References: <8335kg1srp.fsf@gnu.org> <83mtieoxpj.fsf@gnu.org> Reply-To: Alex Hutcheson Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000515dbc05d9040078" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37357"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54027@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 27 19:26:03 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nOOF8-0009VM-1C for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Feb 2022 19:26:02 +0100 Original-Received: from localhost ([::1]:38278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nOOF7-0004Pe-0e for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Feb 2022 13:26:01 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nOOBH-0003Z8-5d for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 13:22:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37056) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nOOBG-0007rG-4I for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 13:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nOOBG-0003dg-0y for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 13:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alex Hutcheson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Feb 2022 18:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54027 X-GNU-PR-Package: emacs Original-Received: via spool by 54027-submit@debbugs.gnu.org id=B54027.164598609913948 (code B ref 54027); Sun, 27 Feb 2022 18:22:01 +0000 Original-Received: (at 54027) by debbugs.gnu.org; 27 Feb 2022 18:21:39 +0000 Original-Received: from localhost ([127.0.0.1]:59181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOOAs-0003cu-Ui for submit@debbugs.gnu.org; Sun, 27 Feb 2022 13:21:39 -0500 Original-Received: from mail-vs1-f44.google.com ([209.85.217.44]:46029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOOAr-0003cb-S7 for 54027@debbugs.gnu.org; Sun, 27 Feb 2022 13:21:38 -0500 Original-Received: by mail-vs1-f44.google.com with SMTP id e5so10770865vsg.12 for <54027@debbugs.gnu.org>; Sun, 27 Feb 2022 10:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zbshs/wiq92oPTC1+HkqkpZsQ3kSOMmfoVjaZicEs9k=; b=hjuh7ABdA+UABmYmF4WpEVpde6WU9RLGhlJbvka7DSRea2YzlxziFlHpSvi7miA4RA 5Jzz8XLimqLw7oF9ROMgDQ/p+n8xvvVNebwIanm6/kjTEf9ex22OZdVe/eQTzyF/d0Ml eIJGaxnWrRGmpVY12uzhvD8zMRR//VL5w524EzQXLO393yIlG7KjqLxvEbVGHGdABN6V zK2vNpI1SqNsrd7RuQf3F0DsdFp990Pp/0Ai9xQ0NyYUYKCx9IzVCxrdiwmANZcEKAlg zTayqExDDp94WzRuXzJ66oD5DRjoJw10nnsIy6RdAW84j1b5/QKROL8fkug9JisrHpj7 Av7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zbshs/wiq92oPTC1+HkqkpZsQ3kSOMmfoVjaZicEs9k=; b=KGcuVDnHcXAwnLjkPqXAaJqYMade12eSeNQWGaYGSyyy+y9UKmdGMBF5SxuGudLh+G xmGIO26nDm3pTlPN5x89b6F+C/26i4mtNsgrDx3OjZ/0ZLBcGPyo98MIuHmyJZZ667D6 HlHa3uMQ+YXkr1K+l5hMG8I0yuwB0MaxMfCi8ual6Lo2CPf2+x6HhxGC5iSuQVjCyAB2 xIss8DcvA+UQZEgd4koKR0BGCFgpphnaHh8HJiWg4Jqcvx6ZLAyJxlMGczdck3G7fwix V+vEujWZ+AYWx/7/EIPgzdthtZ1h93X9gwDJArNxvsGxEXW7a0EQeVpq9wSL8gpi9FJD nghg== X-Gm-Message-State: AOAM533Owp0RqOOZkMNZXjqj327u8HBJjqbcd12Vrc1nDoIGc6CBUGgG u1jJjSqPOvTPvAU9CUtJwbOfSvdpkuEnhPDsLJqobzowSewLWg== X-Google-Smtp-Source: ABdhPJyny3VgtImuKJYuxR+0Gkbwf2YLxi0kb+MyunDho1nGuapW3zgnNFBEyMgO1R/axQbk9TWdcdU5TzcjGQqABoU= X-Received: by 2002:a05:6102:374e:b0:31e:4fee:3ce7 with SMTP id u14-20020a056102374e00b0031e4fee3ce7mr6531073vst.84.1645986091929; Sun, 27 Feb 2022 10:21:31 -0800 (PST) In-Reply-To: <83mtieoxpj.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:227738 Archived-At: --000000000000515dbc05d9040078 Content-Type: text/plain; charset="UTF-8" > I think just adding the missing combinations is a better way forward. I think we're in agreement here, I was just suggesting how to add the combinations to xterm.el without introducing a lot of boilerplate code. We basically need to support the cross-product of: modifier combinations x ASCII characters It seems like there are 7 possible modifier combinations: - Control - Meta - Shift - Control + Meta - Control + Shift - Meta + Shift - Control + Shift + Meta The code in the StackExchange post (https://emacs.stackexchange.com/a/13957 ) doesn't add support for "Meta + Shift" or plain "Shift", because those combinations generally already result in something that doesn't need any special encoding (e.g. a capital letter or symbol, possibly preceded by an ESC character if Meta was pressed). So we only *really* need to support the encodings for the remaining 5. At the same time, it might be reasonable to support the other 2, because they're still valid encodings, so a terminal might still end up sending them. Then we have 95 ASCII characters to support: codes 32 through 126 (inclusive), which covers all the ASCII alphanumeric and punctuation characters. So our keymap will end up with 5 x 95 = 475 entries (or 7 x 95 = 665 if we support Shift and Meta+Shift). To add these entries to xterm.el, we could either: 1. Add 475 lines to xterm.el, with a hard-coded entry for each combination, or 2. Add a nested loop of (modifier combinations x ASCII characters) that generates those 475 entries at runtime when xterm.el is executed. If we implement #2, it would actually allow us to reduce the lines of code in xterm.el, because we could delete the existing hard-coded entries. On Sat, Feb 26, 2022 at 3:10 AM Eli Zaretskii wrote: > > From: Alex Hutcheson > > Date: Tue, 22 Feb 2022 20:07:40 -0500 > > Cc: 54027@debbugs.gnu.org > > > > - A detailed overview of the issue from the maintainer of xterm. > > This covers both the original "CSI 27" encoding and the newer > > "CSI u" encoding: > https://invisible-island.net/xterm/modified-keys.html > > - A much briefer summary: > https://github.com/microsoft/terminal/issues/8719#issuecomment-826528702 > > - The xterm man page (see "formatOtherKeys"): > https://invisible-island.net/xterm/manpage/xterm.html > > > > I also realized that this has actually been discussed in the past, > > and Emacs actually added support for many CSI u sequences to > > xterm.el: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839 > > > > I think the only remaining work is to extend that support to cover > > all reasonable combinations of modifiers and keys, which is what > > the code snippet in the StackExchange answer attempts to do. > > Right, but I'd rather the additional keys followed the same format as > in the above-mentioned patch by Stefan, posted in bug#13839, because > that is what we have in xterm.el nowadays. > > > We're currently hard-coding the possible combinations of > > modifiers and keys that we support: > > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/term/xterm.el#n464 > > An alternative approach would be to replace that hard-coded list > > with a programatically-generated list that includes every combination > > of modifiers and keys. > > I'm not sure I understand how you can programmatically generate a list > of keys: wouldn't it still involve a manually-maintained list at some > level? > > I think just adding the missing combinations is a better way forward. > > Thanks. > -- Alex Hutcheson alexhutcheson@google.com --000000000000515dbc05d9040078 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I think just adding the missing combinations is = a better way forward.

I think we're in agreeme= nt here, I was just suggesting how to add=C2=A0
the combinations = to xterm.el without introducing a lot of boilerplate
code.
<= div>
We basically need to support the cross-product of:
modifi= er combinations x ASCII characters

It seems like t= here are 7 possible modifier combinations:
- Control
- = Meta
- Shift
- Control=C2=A0+ Meta
- Control= =C2=A0+ Shift
- Meta=C2=A0+ Shift
- Control= =C2=A0+ Shift=C2=A0+ Meta

The code in the StackExc= hange post (https://ema= cs.stackexchange.com/a/13957)=C2=A0
doesn't add support f= or "Meta=C2=A0+ Shift" or plain "Shift", because those = combinations
generally already=C2=A0result in something that does= n't need any special encoding=C2=A0
(e.g. a capital letter or= symbol, possibly preceded by an ESC character if Meta was
presse= d). So we only *really* need to support=C2=A0the encodings for the remainin= g 5.
At the same time, it might be reasonable to support the othe= r 2, because they're
still valid encodings, so a terminal mig= ht still end up sending them.

Then we have 95 ASCI= I characters to support: codes 32 through 126 (inclusive), which
= covers all the ASCII alphanumeric and punctuation characters.
So our keymap will end up with 5 x 95 =3D 475 entries=C2=A0
(or 7 x 95 =3D 665 if we support Shift and Meta+Shift).
To add these entries to xterm.el, we could either:
1= . Add 475 lines to xterm.el, with a hard-coded entry for each combination, = or
2. Add a nested loop of (modifier combinations x ASCII charact= ers) that=C2=A0
=C2=A0 generates those 475 entries at runtime whe= n xterm.el is executed.

If we implement #2, it wou= ld actually allow us to reduce the lines of code in xterm.el,
bec= ause we could delete the existing hard-coded entries.

On Sat, Feb 26, = 2022 at 3:10 AM Eli Zaretskii <eliz@gnu.= org> wrote:
> From: Alex Hutcheson <alexhutcheson@google.com>
> Date: Tue, 22 Feb 2022 20:07:40 -0500
> Cc: 54027@d= ebbugs.gnu.org
>
> - A detailed overview of the issue from the maintainer of xterm.
>=C2=A0 =C2=A0This covers both the original "CSI 27" encoding = and the newer
>=C2=A0 =C2=A0"CSI u" encoding: ht= tps://invisible-island.net/xterm/modified-keys.html
> - A much briefer summary: https://github.com/microsoft/terminal/issues/8719#issuecomment-826528702=
> - The xterm man page (see "formatOtherKeys"): https://invisible-island.net/xterm/manpage/xterm.html
>
> I also realized that this has actually been discussed in the past,
> and Emacs actually added support for many CSI u sequences to
>=C2=A0 xterm.el: https://debbugs.gnu.org/cg= i/bugreport.cgi?bug=3D13839
>
> I think the only remaining work is to extend that support to cover
> all reasonable combinations of modifiers and keys, which is what
> the code snippet in the StackExchange answer attempts to do.

Right, but I'd rather the additional keys followed the same format as in the above-mentioned patch by Stefan, posted in bug#13839, because
that is what we have in xterm.el nowadays.

> We're currently hard-coding the possible combinations of
> modifiers and keys that we support:
> https://git.savannah.gn= u.org/cgit/emacs.git/tree/lisp/term/xterm.el#n464
> An alternative approach would be to replace that hard-coded list
> with a programatically-generated list that includes every combination =
> of modifiers and keys.

I'm not sure I understand how you can programmatically generate a list<= br> of keys: wouldn't it still involve a manually-maintained list at some level?

I think just adding the missing combinations is a better way forward.

Thanks.


--
--000000000000515dbc05d9040078--