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: Delegating user-reserved key binding space definition to users Date: Mon, 28 Nov 2022 20:38:47 -0600 Message-ID: References: <57b69c22e167d429d21bb969feb22887@webmail.orcon.net.nz> <877czikyfa.fsf@localhost> <87o7sthrwx.fsf@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000dd929505ee92e389" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5685"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ihor Radchenko , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 29 03:39:54 2022 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 1ozqXK-0001Fq-3e for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Nov 2022 03:39:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozqWY-0000u7-Kf; Mon, 28 Nov 2022 21:39:06 -0500 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 1ozqWW-0000tk-Ny for emacs-devel@gnu.org; Mon, 28 Nov 2022 21:39:04 -0500 Original-Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ozqWT-0004RI-ND for emacs-devel@gnu.org; Mon, 28 Nov 2022 21:39:04 -0500 Original-Received: by mail-pj1-x102c.google.com with SMTP id o5-20020a17090a678500b00218cd5a21c9so11990351pjj.4 for ; Mon, 28 Nov 2022 18:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9chMHKgxIvywSECnRpr/QiZ0ucfy76fdDnMrsoV1mCw=; b=npR6pzubJP5pvkRBkx/RJIkEKC/xMyHz5BzKD5bcG3SSO8YRaPTWPAZn2K5peiOoV3 Z5bAiJIeZAbHFD9pIsgOdqr4s3O48xfW9+c1SemI1UA+UxtCJIrjeUser6pjiAoU90T/ Se6rtvJHgSGowEqgcLLpmXiZCXfZv4ldwNFPrmUrma9gReXaV71IQCZx9huwVocIH1ie 5NV0J8iokiROq7izAJyobojSiso0tkEPhsztdjNTSqF8R8rjemCIn/e4N+uXYcwlwb0R //dkmuohYgt4zMJrfvr+C1zFUoArkt3vmgDrIFrGHpiCB8z5yG0bvJRCXho1wHQt4HQe EWkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=9chMHKgxIvywSECnRpr/QiZ0ucfy76fdDnMrsoV1mCw=; b=Yw6nIRNdcxJMcrpnAz/HMW5gCyTk5hb0VubZI3UUFQUTQR9EAtpMvYUCwpCUu6U7c7 NEVbW3Ai59GlwQPV9e0PTgIa4y4ry/Wt1Mfv14Fg7AJ/KRzLCEK4z5j+h40AK7hKSDpk 7mzTG/0u1wiBsARB87cPV0mj1JsirEDIfsZQ/wh0o2gB1mBy9Ill+3vT8XTAe4h2Bj2c 31xzuOMEu+/UxFKvc6bYl/KNGhRUVI5rfhALZCXYNr+wew9wt/1Ja9FeXXfiAE1RW6VD JpHrDdEIKbXIUT2vZEy/SVi8lAxGzLjDXlaxw3KqRiJM6pix7Qgd7pNCz8+EB6wGsllB ejaQ== X-Gm-Message-State: ANoB5pkiEhJQhY3tz9MgNRQ1lgUA4YwOQRyNQlRdbiAqEdZXwKHLg8UX zZlSygYJIwBZ/SDUA5xyXDAeJB6ABnQcKwugCMIEYA== X-Google-Smtp-Source: AA0mqf7t8aVD5Jxn/7+JG3kyW1IgAMxSiu/sl5AO0TMUk0abcOqArKwsZJhs3WuFGqOLqI4y/AaqZ7m4JckjjZvgHAo= X-Received: by 2002:a17:902:aa06:b0:183:7f67:25d7 with SMTP id be6-20020a170902aa0600b001837f6725d7mr35366170plb.164.1669689539130; Mon, 28 Nov 2022 18:38:59 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::102c; envelope-from=exec@positron.solutions; helo=mail-pj1-x102c.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 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:300696 Archived-At: --000000000000dd929505ee92e389 Content-Type: text/plain; charset="UTF-8" > a solution should allow packages to declare that command FOO > should be bound to some key based on SOME-INFO, such that it will be > bound to one key in "normal Emacs mode", and to another in `evil-mode` > and to yet another in `god-mode`, etc... SOME-INFO will be of the form: ((concept command) (concept command) ...)) ; package provide ((concept (concept concept concept)) (concept concept)) ; overload remappings, perhaps user or package provided or both ((concept binding) (concept binding)) ; user or emulation mode etc provided The overloads might be embedded in the first and second lists, but it will make for complicated reading later. Either a built-in implementation in Emacs or customized implementations in packages should consume the full SOME-INFO and generate keymaps. If that keymap generation is dynamic or the keymap itself embeds indirection for contextual operations, we get essentially dynamic dispatch, and there's not much need for new implementations. emulation-mode-map-alists has its structure for good reason. In the beginning, before packages provide their half, the user will provide it, likely through a package. This is analogous to evil collection. There likely will not be enough concepts to support relocating every key this way. While the default implementation that ships with Emacs can attempt to rearrange keys usings current behavior and a heuristic where that is not possible, if the user configures a different implementation, even one that ignores the mode's SOME-INFO in part or whole, commands will be unbound. This is good. We have to support the notion that the provided commands are bad and that the users wants to write better ones or else we are choking the evolution of the interaction models. Package authors should focus on good functions and editing data models. This is what makes it easy to write good commands. Attempting to write all the good commands is not possible without lots of user representation, which package authors cannot individually have. > To me a solution should allow packages to declare that command FOO > should be bound to some key based on SOME-INFO, such that it will be > bound to one key in "normal Emacs mode", and to another in `evil-mode` > and to yet another in `god-mode`, etc... This places too much emphasis on package authors. They should only provide the ((concept command)) information. Package authors and users have to meet in the middle, and remember to put the users first in that discussion. As stated above, I believe it's the job of modal systems to decide how to consume the package-defined half of SOME-INFO. > Agreed. But it should apply to all bindings. The concepts that can be good targets in SOME-INFO should arise only very naturally. This means there will be way too few concepts to handle the current state of keymaps. IMO this is because package authors feel entitled to users' keyboards or obligated to shadow all of the random commands bound in the default global map. The implementations should make it easier for bad commands / bindings to die. Lots of Emacs applications handle lists of options because lists are simply ubiquitous, and so navigating lists is naturally a common concept. M-x is the gateway to commands, and Emacs without such a gateway is degenerate, so we need that as a concept. Aborting a command that is asking for input or blocking on network is a concept. Let's get these figured out and make them easily remappable before worrying about esoteric commands that the user might want to redefine anyway. On Mon, Nov 28, 2022 at 12:15 PM Stefan Monnier wrote: > >>> I suggest introducing a notion of "generalized" commands. Such commands > >>> will represent common actions executed by users (like move to > >>> next/previous element). Major and minor modes can then define specific > >>> implementation of the actions. > >> > >> I think it's a non-starter because it requires foresight: only those > >> commands defined with this mechanism will be extensible. I agree that > >> an additional level of indirection is probably necessary, but I suspect > >> it needs to be placed elsewhere. > > > > Auto-remapping will need some kind of grouping for commands one way or > > another. There is no way we can do it auto-magically. Developer or users > > should decide. > > Agreed. But it should apply to all bindings. > > > Currently, the commands in major mods are bound to specific key > > bindings. The bindings are chosen either arbitrarily, according to major > > mode author preferences, or according to semi-established default key > > binding scheme (like C-f/C-M-f/C-n/C-v/etc). Either way, trying to > > re-bind commands in multiple major modes is not easy. > > Yup. I fully agree that it's a real problem. > > I'd welcome a solution to it. Even an "unrealistic" one would be good. > Currently, I don't even know what a good solution could look like. > > To me a solution should allow packages to declare that command FOO > should be bound to some key based on SOME-INFO, such that it will be > bound to one key in "normal Emacs mode", and to another in `evil-mode` > and to yet another in `god-mode`, etc... > > Some SOME-INFO needs to provide not a specific key, but some information > from which we can compute the "natural key" that fits the keybinding > style that the user selected. > > Then there are also the issues of overloading several operations on > a single key (like TAB). So far we've solved this along the lines you > suggest (a "generalized command", such as `indent-for-tab-command`), and > maybe that's good enough for this, tho it prevents changing this > overloading according to the keybinding style. > > [ BTW, another way to look at it is not "how can we compute which key to > bind FOO to" but rather "how can we compute which command to run when > KEY is hit". IOW, we could make keymaps more dynamic such that when > you hit KEY, Emacs passes that to a "procedural keymap" which will > *compute* (rather than lookup) which command to run, according to the > current keybinding style. > Not sure it would be better: I just mention it as one of the many > things that we may want to consider in order to find a good solution > to the problem. ] > > >> [ FWIW, you can get similar results with the current setup using > >> command remapping. ] > > You are absolutely right: when a major mode command is related to > > built-in command in command map. > > Just to be clear: I don't think command remapping solves the problem > at hand. It can sometimes be used for that, but not in general. > > > However, some major modes introduce new concepts. For example, think > > about paredit-forward-slurp-sexp, which can be an equivalent of Org's > > heading promotion or moving word at point forward in sentences. How > > could you remap to group these 3 very different yet similar (for some > > users) commands together? > > Great example, indeed, thanks. > > In this context, I'd like the package to be able to explain that this > command is about a "sexp"-granularity operation and about > "forward"-direction operation, so that the keybinding style may > automatically find a natural/consistent key (or set of keys) to use for > it depending on whether the current keybinding style uses f/b, or j/k, > or left/right, or ... for forward/backward operations. > > > Stefan > > -- Psionic K Software Engineer *Positron Solutions * --000000000000dd929505ee92e389 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> a solution should allow= packages to declare that command FOO
> should be bound to some key based on SOME-INFO, such that it will be > bound to one key in "normal Emacs mode", and to another in `= evil-mode`
> and to yet another in `god-mode`, etc...

= SOME-INFO will be of the form:
((concept command) (concept co= mmand) ...)) ; package provide
((concept (concept concept con= cept)) (concept concept)) ; overload remappings, perhaps user or package pr= ovided or both
((concept binding) (concept binding)) ; user o= r emulation mode etc provided

The overloads might be embe= dded in the first and second lists, but it will make for complicated readin= g later.

Either a built-in implementation in E= macs or customized implementations=20 in packages should consume the full SOME-INFO and generate keymaps.=C2=A0 I= f that keymap generation is dynamic or the keymap itself embeds indirection= for contextual operations, we get essentially dynamic dispatch, and there&= #39;s not much need for new implementations.=C2=A0 emulation-mode-map-alist= s has its structure for good reason.

In the beginning, be= fore packages provide their half, the user will=20 provide it, likely through a package.=C2=A0 This is analogous to evil=20 collection.

There likely will not be enough concepts to s= upport relocating every key this way.=C2=A0 While the default implementatio= n that ships with Emacs can attempt to rearrange keys usings current behavi= or and a heuristic where that is not possible, if the user configures a dif= ferent implementation, even one that ignores the mode's SOME-INFO in pa= rt or whole, commands will be unbound.=C2=A0 This is good.=C2=A0 We have to= support the notion that the provided commands are bad and that the users w= ants to write better ones or else we are choking the evolution of the inter= action models.=C2=A0 Package authors should focus on good functions and edi= ting data models.=C2=A0 This is what makes it easy to write good commands.= =C2=A0 Attempting to write all the good commands is not possible without lo= ts of user representation, which package authors cannot individually have.<= /div>

> To me a solution should allow pac= kages to declare that command FOO
> should be bound to some key based= on SOME-INFO, such that it will be
> bound to one key in "normal Emacs mode", and to another in `= evil-mode`
> and to yet another in `god-mode`, etc...

= This places too much emphasis on package authors.=C2=A0 They should only pr= ovide the ((concept command)) information.=C2=A0 Package authors and users = have to meet in the middle, and remember to put the users first in that dis= cussion.=C2=A0 As stated above, I believe it's the job of modal systems= to decide how to consume the package-defined half of SOME-INFO.

 > Agreed.=C2=A0 But it should apply to all bindings.

The concepts that can= be good targets in SOME-INFO should arise only very naturally.=C2=A0 This = means there will be way too few concepts to handle the current state of key= maps.=C2=A0 IMO this is because package authors feel entitled to users'= keyboards or obligated to shadow all of the random commands bound in the d= efault global map.=C2=A0 The implementations should make it easier for bad = commands / bindings to die.

Lots of Emacs applications handle lists = of options because lists are simply ubiquitous, and so navigating lists is = naturally a common concept.=C2=A0 M-x is the gateway to commands, and Emacs= without such a gateway is degenerate, so we need that as a concept.=C2=A0 = Aborting a command that is asking for input or blocking on network is a con= cept.=C2=A0 Let's get these figured out and make them easily remappable= before worrying about esoteric commands that the user might want to redefi= ne anyway.

On Mon, Nov 28, 2022 at 12:15 PM Stefan Monnier &= lt;monnier@iro.umontreal.ca= > wrote:
>= >> I suggest introducing a notion of "generalized" commands= . Such commands
>>> will represent common actions executed by users (like move to<= br> >>> next/previous element). Major and minor modes can then define = specific
>>> implementation of the actions.
>>
>> I think it's a non-starter because it requires foresight: only= those
>> commands defined with this mechanism will be extensible.=C2=A0 I a= gree that
>> an additional level of indirection is probably necessary, but I su= spect
>> it needs to be placed elsewhere.
>
> Auto-remapping will need some kind of grouping for commands one way or=
> another. There is no way we can do it auto-magically. Developer or use= rs
> should decide.

Agreed.=C2=A0 But it should apply to all bindings.

> Currently, the commands in major mods are bound to specific key
> bindings. The bindings are chosen either arbitrarily, according to maj= or
> mode author preferences, or according to semi-established default key<= br> > binding scheme (like C-f/C-M-f/C-n/C-v/etc). Either way, trying to
> re-bind commands in multiple major modes is not easy.

Yup.=C2=A0 I fully agree that it's a real problem.

I'd welcome a solution to it.=C2=A0 Even an "unrealistic" one= would be good.
Currently, I don't even know what a good solution could look like.

To me a solution should allow packages to declare that command FOO
should be bound to some key based on SOME-INFO, such that it will be
bound to one key in "normal Emacs mode", and to another in `evil-= mode`
and to yet another in `god-mode`, etc...

Some SOME-INFO needs to provide not a specific key, but some information from which we can compute the "natural key" that fits the keybind= ing
style that the user selected.

Then there are also the issues of overloading several operations on
a single key (like TAB).=C2=A0 So far we've solved this along the lines= you
suggest (a "generalized command", such as `indent-for-tab-command= `), and
maybe that's good enough for this, tho it prevents changing this
overloading according to the keybinding style.

[ BTW, another way to look at it is not "how can we compute which key = to
=C2=A0 bind FOO to" but rather "how can we compute which command = to run when
=C2=A0 KEY is hit".=C2=A0 IOW, we could make keymaps more dynamic such= that when
=C2=A0 you hit KEY, Emacs passes that to a "procedural keymap" wh= ich will
=C2=A0 *compute* (rather than lookup) which command to run, according to th= e
=C2=A0 current keybinding style.
=C2=A0 Not sure it would be better: I just mention it as one of the many =C2=A0 things that we may want to consider in order to find a good solution=
=C2=A0 to the problem.=C2=A0 ]

>> [ FWIW, you can get similar results with the current setup using >>=C2=A0 =C2=A0command remapping.=C2=A0 ]
> You are absolutely right: when a major mode command is related to
> built-in command in command map.

Just to be clear: I don't think command remapping solves the problem at hand.=C2=A0 It can sometimes be used for that, but not in general.

> However, some major modes introduce new concepts.=C2=A0 For example, t= hink
> about paredit-forward-slurp-sexp, which can be an equivalent of Org= 9;s
> heading promotion or moving word at point forward in sentences.=C2=A0 = How
> could you remap to group these 3 very different yet similar (for some<= br> > users) commands together?

Great example, indeed, thanks.

In this context, I'd like the package to be able to explain that this command is about a "sexp"-granularity operation and about
"forward"-direction operation, so that the keybinding style may automatically find a natural/consistent key (or set of keys) to use for
it depending on whether the current keybinding style uses f/b, or j/k,
or left/right, or ... for forward/backward operations.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan



--

Software Engineer
<= /div>
--000000000000dd929505ee92e389--