From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.devel Subject: Re: seeking feedback on keymaps introspection tool Date: Thu, 1 Jun 2023 07:18:34 -0500 Message-ID: References: <87sfbddfne.fsf@localhost> <87353coojd.fsf@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000023e0b905fd1070ab" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37332"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 01 14:23:45 2023 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 1q4hLC-0009J0-1W for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Jun 2023 14:23:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4hHA-00075K-16; Thu, 01 Jun 2023 08:19:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4hGZ-0006mK-Fw for emacs-devel@gnu.org; Thu, 01 Jun 2023 08:19:06 -0400 Original-Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q4hGT-0007lT-Bm for emacs-devel@gnu.org; Thu, 01 Jun 2023 08:18:55 -0400 Original-Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-1b038064d97so16362805ad.0 for ; Thu, 01 Jun 2023 05:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1685621926; x=1688213926; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BD5BgY0LY4W6gElrkC8ok+L9DunvGj5LiayOqQrU4m8=; b=o0dC6RKEKXIgbQRYU5QvXi4jrl1tfITfntKcekm0C37d62wgM2C9wUY3q5xD90d3VH rmf0XYY5WqnuxZl9FP2fNU3lhBTFZL7NL4TeCKq20YyvTHbt4f+HfCeN4zyH0WnvVViy b3CQvmjnCg4hL65WakmOjk30AkOU3WTgpvIQ0xkoTqG1XMmg+htfbWGH8lTAvBoL/evd PSeh4urD14BD+bI8zK8aOitUdNSXOy5lTAcCTsmvUCgBvkw0vEB2Dw0K96iz12thxKwB mYcj54soAKEMywGs01pn5SOIZfxc/XpUpMdDxs3SlbSAPr+uvoJTx7WyP2mo/W/dPGd7 P7OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685621926; x=1688213926; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BD5BgY0LY4W6gElrkC8ok+L9DunvGj5LiayOqQrU4m8=; b=VbX0Lvp52nG1RlDfHDEarZ4IZ/N3+HsO345g+xiHDN9stPxGMLlqmw4/CvaZOtN9yE Umb32ciDAPr9hI4o6R8FPnPo+xdjs8B0Ot5rtitUALt2z0BhPhtGC1PL26gMG4K8uG4Y 9zrtjuGwuUMZJcem3qozMx8jWYr/J6lqrUZP1kSG45YqSQy3RQWahaGo2J1jEpsB0ylT Kq6bRlNGi9gYgCcwk3nBiDlCwTqiG5T2jJTeXsBG9qENeW3WBaTCZkak3EmsLrYzFH9r 2yFB5rKyQ12alQ9WOCdNiz27CZy3OYX4+6ydfhJKUImYI5CAUhZ7eonHCNckX8Jt41oO JWrw== X-Gm-Message-State: AC+VfDzxMva7Wli7qERe/0rZ4/iazbA5XPRfoLRcgFtFCBHiFnQReykn 1NfGs+cxegRtgv2c+7/ydJBZ2xD2p4saTxADGh6RX6NTp24ev31Qwl0= X-Google-Smtp-Source: ACHHUZ6P/XMClyzMITaguQH68dtt1e578pzntuY3x19Pep8dcNeRETGHZMty2S/hdFOuszp1AEgvFjxzRrX2bjNFjW0= X-Received: by 2002:a17:902:8341:b0:1a1:cb18:7f99 with SMTP id z1-20020a170902834100b001a1cb187f99mr1560480pln.30.1685621926250; Thu, 01 Jun 2023 05:18:46 -0700 (PDT) In-Reply-To: <87353coojd.fsf@localhost> Received-SPF: pass client-ip=2607:f8b0:4864:20::62e; envelope-from=exec@positron.solutions; helo=mail-pl1-x62e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306512 Archived-At: --00000000000023e0b905fd1070ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I finished a rough proof-of-concept for abstract commands on top of command remapping. I used a macro to generate a mass rebind expression. I can still use C-n and C-p. I can rebind the abstract commands and all of the other commands follow. If I add bindings to #'abstract-next to C-; for example, all of the re-mapped commands are available on that sequence and shadow appropriately. Pretty print the macro at the bottom of the user-keys-abstract package see a mass rebranding expression: https://github.com/positron-solutions/user-keys/blob/master/lisp/user-keys-= abstract.el The tests also demonstrate the outputs, but are less realistic. I am currently using Emacs with all of the mentioned keys rebound by the macro call. The first example of growing pains I found is that Ivy actually already uses a remap to next-line. Since it wasn't a built-in Emacs map, I didn't include it in my example macro. I would have to work on the macro and expression generation to handle remap detection when performing a move, but this is more a matter of plumbing than complexity. I was able to use my reporting functionality from the user-keys package to identify maps to start working on. The commented expressions in the macro caused errors (binding in the widget-global-map affects the global-map?) or strange behavior I don't want to invest time in before validating the use cases. What I would recommend for Emacs is to implement a first-class named-key that doesn't have the implementation limitations of the remap only going through one layer. I would be able to focus on making user-keys into a better diagnosis and generation tool if I avoid going too deep on top of the remap-based implementation, which has the one-indirection depth limitation. I'll publish the package pretty soon with some small coherence improvements. While looking at emulation maps, I realized some of them won't have symbols for example, so I need to figure out a way to represent the idea to the user. I've worked a bit on generating mass unbinds by refactoring the reporting logic and it generally looks like there won't be difficulty. On Wed, May 31, 2023 at 4:05=E2=80=AFAM Ihor Radchenko wrote: > Psionic K writes: > > > > https://github.com/positron-solutions/user-keys/blob/master/lisp/user-key= s.el#L142-L147 > > Nice. > > Another idea: some key bindings are risky when using Emacs from > terminals. For example, bindings like M- often do not work in > terminals. It would be nice to provide some hints about which keys may > not work in terminals, at least approximately (doing this precisely > depends on terminal being used and is generally not easy). > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --=20 Psionic K Software Engineer *Positron Solutions * --00000000000023e0b905fd1070ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I finished a rough proof-of-concept for abstract comm= ands on top of command remapping.=C2=A0 I used a macro to generate a mass r= ebind expression.=C2=A0 I can still use C-n and C-p.=C2=A0 I can rebind the= abstract commands and all of the other commands follow.=C2=A0 If I add bin= dings to #'abstract-next to C-; for example, all of the re-mapped comma= nds are available on that sequence and shadow appropriately.
=
Pretty print the macro at the bottom of the user-keys-abstra= ct package see a mass rebranding expression:
htt= ps://github.com/positron-solutions/user-keys/blob/master/lisp/user-keys-abs= tract.el

The tests also demonstrate the output= s, but are less realistic.

I am currently using E= macs with all of the mentioned keys rebound by the macro call.=C2=A0 The fi= rst example of growing pains I found is that Ivy actually already uses a re= map to next-line.=C2=A0 Since it wasn't a built-in Emacs map, I didn= 9;t include it in my example macro.=C2=A0 I would have to work on the macro= and expression generation to handle remap detection when performing a move= , but this is more a matter of plumbing than complexity.

I was able to use my reporting functionality from the user-keys pack= age to identify maps to start working on.=C2=A0 The commented expressions i= n the macro caused errors (binding in the widget-global-map affects the glo= bal-map?) or strange behavior I don't want to invest time in before val= idating the use cases.

What I would recommend for = Emacs is to implement a first-class named-key that doesn't have the imp= lementation limitations of the remap only going through one layer.=C2=A0 I = would be able to focus on making user-keys into a better diagnosis and gene= ration tool if I avoid going too deep on top of the remap-based implementat= ion, which has the one-indirection depth limitation.

I= 9;ll publish the package pretty soon with some small coherence improvements= .=C2=A0 While looking at emulation maps, I realized some of them won't = have symbols for example, so I need to figure out a way to represent the id= ea to the user.=C2=A0 I've worked a bit on generating mass unbinds by r= efactoring the reporting logic and it generally looks like there won't = be difficulty.

On Wed, May 31, 2023 at 4:05=E2=80=AFAM Ihor Radche= nko <yantar92@posteo.net> = wrote:
Psionic K= <psionik@positron.solutions> writes:

> https://= github.com/positron-solutions/user-keys/blob/master/lisp/user-keys.el#L142-= L147

Nice.

Another idea: some key bindings are risky when using Emacs from
terminals. For example, bindings like M-<RET> often do not work in terminals. It would be nice to provide some hints about which keys may
not work in terminals, at least approximately (doing this precisely
depends on terminal being used and is generally not easy).

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>


--
<= /div>

Psionic K
<= /div>Software Engineer
<= /div>
--00000000000023e0b905fd1070ab--