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:53:56 -0500 Message-ID: References: <8335kg1srp.fsf@gnu.org> <83mtieoxpj.fsf@gnu.org> <837d9gnoig.fsf@gnu.org> Reply-To: Alex Hutcheson Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000dba95805d90474ee" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27190"; 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:56:38 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 1nOOik-0006w3-7K for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Feb 2022 19:56:38 +0100 Original-Received: from localhost ([::1]:37902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nOOii-0007u6-V5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Feb 2022 13:56:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39314) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nOOhD-0006Aw-3h for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 13:55:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37081) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nOOhC-0007QN-Qs for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 13:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nOOhC-0004RQ-Lj for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 13:55: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:55:02 +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.164598805517011 (code B ref 54027); Sun, 27 Feb 2022 18:55:02 +0000 Original-Received: (at 54027) by debbugs.gnu.org; 27 Feb 2022 18:54:15 +0000 Original-Received: from localhost ([127.0.0.1]:59211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOOgR-0004QJ-15 for submit@debbugs.gnu.org; Sun, 27 Feb 2022 13:54:15 -0500 Original-Received: from mail-ua1-f50.google.com ([209.85.222.50]:33725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOOgP-0004Q5-0Q for 54027@debbugs.gnu.org; Sun, 27 Feb 2022 13:54:13 -0500 Original-Received: by mail-ua1-f50.google.com with SMTP id 4so5009655uaf.0 for <54027@debbugs.gnu.org>; Sun, 27 Feb 2022 10:54:12 -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=8LB1oyhhVHTFAKpBIncXWk9fzAbLeQGDW3Fwb5roZWQ=; b=GXsEngxlvOeqsS9FLnQup+0790Jw0S3Mx1L3RukTB4L9pHM3Fd1aEqTJL1kYFOrdYZ T8iwnvtQNGRQECy3RdlPWaYrfmpzRMBoEBrdXAI85vPt1f3NFQ6WkZ9WVJzwNQtOfDJu LX4inUXQZ1FmLAPnYgJ0GrRHTtR75DwfXV4xKJh/5xJguLPCOmgWW1h8FQYF/lpQRbVf XfhJYZHp83FncjkTIbesKc/VT9dpH+GgWhCB5RdaSHFnOHVQ4YkzYi5yEafOEf6LSIhT 4acibPsFGYh0mwiln9rkgSnPv9uFpl8WStenyuEWs6e9ijBNC78UsvVEt9AGTq5YpGRL Qmfw== 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=8LB1oyhhVHTFAKpBIncXWk9fzAbLeQGDW3Fwb5roZWQ=; b=ViHguHY8AGAA/NcHNrIPxpYoWzQ6SqsTFe5FeuGMZ9SAaX8FhRzdNOHXuesUekiw6Q VeGZMmavYzPuG0teIWlLwKHDvU/KeNf+5TTPBKATOH8B/HKQyLTKOLO5Nb1QgEUhd+6B IN4dVNMU3N0Sy3KlDmIu4TbcwzwNho2+zsevGa3W8u9nG6En9QHX65gy5GOrU3Yd4G7d NB9JNbyudzMbpCjjrssQeGAcaUodfDecSR4H8aO6mQsJ8ZGvzEtGK2Brl7pnbJIeo+DB r7/p/cDRWxq93PEV+IbVALA9NFfVyuFLQWdAIr/2YwcYEKJF16aUJ2CZOgWe7m7oJrEZ 2bxg== X-Gm-Message-State: AOAM530yp36q5rprPZCICJ6lyMQBub24NZrol9oOWwHYQX5kKGVLkToJ y3Yf5RAHT9FC+ye8yAp3Seag/9PledWh6Wq+wGyi31dkY3Y+JQ== X-Google-Smtp-Source: ABdhPJwLm3egQjTXDtSdK4gO72Q+16mRNQovwBbMR/At1W+5dPOa0AqqiYdt/YGdbTy8EtN+RDJ3wrsZDdNHwuCXDpM= X-Received: by 2002:ab0:6989:0:b0:346:b33f:7b94 with SMTP id t9-20020ab06989000000b00346b33f7b94mr2810463uaq.5.1645988047180; Sun, 27 Feb 2022 10:54:07 -0800 (PST) In-Reply-To: <837d9gnoig.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:227741 Archived-At: --000000000000dba95805d90474ee Content-Type: text/plain; charset="UTF-8" My thinking is that it's very low-cost to support all possible encodings, even if it's unlikely that a terminal would actually send them. Using your example: \e[65;5u Would be a valid way to encode C-a according to the spec at http://www.leonerd.org.uk/hacks/fixterms/ Most terminals will not encode it that way, and will instead send ^A, but it would be nice to support it gracefully if a terminal happens to send C-a encoded that way. In addition, the "just support all inputs encoded this way" approach seems simpler to understand and maintain than an approach that distinguishes between key combinations that have an existing alternative encoding and those that don't. The entries in the keymap won't be referenced unless Emacs actually receives matching input, so the cost of having entries for additional combinations seems fairly minimal. Maybe I'm misunderstanding keymap performance or some other important parameter, though? On Sun, Feb 27, 2022 at 1:38 PM Eli Zaretskii wrote: > > From: Alex Hutcheson > > Date: Sun, 27 Feb 2022 13:21:20 -0500 > > Cc: 54027@debbugs.gnu.org > > > > We basically need to support the cross-product of: > > modifier combinations x ASCII characters > > No, AFAIU we only need to support keys+modifiers that are not > otherwise supported already. E.g., C-a is already supported, so we > don't need to add it, and similarly many other combinations are > already supported. Or what am I missing? > -- Alex Hutcheson alexhutcheson@google.com --000000000000dba95805d90474ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My thinking is that it's very low-cost to support all = possible encodings,=C2=A0
even if it's unlikely that a terminal wou= ld actually send them.

Using your example:
\e[65;5u
Would be a valid way to encode C-a according to the s= pec at=C2=A0

Most terminals will not encode it that way, and will instead send ^A,=C2= =A0
but it would be nice to support it gracefully if a terminal h= appens to=C2=A0
send C-a encoded that way.

In addition, the "just support all inputs encoded this way" ap= proach
seems simpler to understand and maintain than an approach = that
distinguishes between key combinations that have an existing= =C2=A0
alternative encoding and those that don't.
T= he entries in the keymap won't be referenced unless Emacs actually
receives matching input, so the cost of having entries for additional=
combinations seems fairly minimal.

Mayb= e I'm misunderstanding keymap performance or some other
impor= tant parameter, though?

On Sun, Feb 27, 2022 at 1:38 PM Eli Zaretskii= <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">> From: Alex Hutcheson = <alexhutch= eson@google.com>
> Date: Sun, 27 Feb 2022 13:21:20 -0500
> Cc: 54027@d= ebbugs.gnu.org
>
> We basically need to support the cross-product of:
> modifier combinations x ASCII characters

No, AFAIU we only need to support keys+modifiers that are not
otherwise supported already.=C2=A0 E.g., C-a is already supported, so we don't need to add it, and similarly many other combinations are
already supported.=C2=A0 Or what am I missing?


--
--000000000000dba95805d90474ee--