Re: Delegating user-reserved key binding space definition to users

[Psionic K <psionik@positron.solutions>]

[-- Attachment #1: Type: text/plain, Size: 4846 bytes --]

I tested remap shadowing just now, and it works in 28.2.  A higher
precedence remap will shadow a lower precedence remap.  This means the user
can bind a sequence to an abstract command, give it a remap in the global
map, and have a different remap in a mode map.  When the user rebinds the
abstract command, everything goes with it.

> 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.

We can do this with shadowing in higher precedence maps.  As above, this
works for command remapping, but the issue is that we need a solid place to
remap to, not a command that the user might replace.  If the user defines a
command like "next-line-unfold" in the the global map, a mode generating a
map by looking for "next-line" would not find the correct target.

This is the situation today, with ad-hoc imitation of the default global
map.  Modes map to sequences without knowing what the user wants those
sequences to be.  We basically need a convention to name the keys through
abstract commands instead of using sequences, which really are zero
indication of what the user wants that key to do.  Binding sequences to
abstract commands completely solves this.

>You cannot achieve this by simple remapping, AFAIK.

Each major mode map would shadow the global map's shadow of the
"user-right" abstract command.  Instead of the abstract command sequence
remapping to the global concrete command, the major mode's concrete command
remap would take precedence.  Totally works.


On Sat, Nov 26, 2022 at 11:44 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >> 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.
>
> 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.
>
> Note that a number of commands like `comment-forward' already expect
> major modes to fit into an established, pre-defined framework by
> tweaking the `comment-forward' customization according to the major
> mode. This also requires a foresight.
>
> My suggestion is somewhat similar to the existing practices of major
> mode writing where the author is required to configure comment handling,
> paragraph handling, sentence rules, imenu, etc.
>
> However, what I suggest is more flexible as it does not require Emacs
> core developers to provide extensive configuration mechanism for, say,
> `next-line' individually; `previous-line' individually, ...
> Instead, it will be sufficient to declare generalized command and then
> rely on major modes to hook in. Users should be able to do it easily
> too.
>
> > [ 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.
>
> 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?
>
> I imagine that users can define a generalized command "move right"
> themselves, give it a default binding in overriding global map, and then
> make `paredit-forward-slurp-sexp', `org-promote', and `transpose-words'
> be selected when running "move right" depending on the active major
> mode. You cannot achieve this by simple remapping, AFAIK.
>
> --
> 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>
>


-- 

Psionic K <psionik@positron.solutions>
Software Engineer

*Positron Solutions <https://positron.solutions>*

[-- Attachment #2: Type: text/html, Size: 6774 bytes --]