unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Psionic K <psionik@positron.solutions>,
	 Emacs developers <emacs-devel@gnu.org>
Subject: Re: Delegating user-reserved key binding space definition to users
Date: Sun, 27 Nov 2022 05:45:18 +0000	[thread overview]
Message-ID: <87o7sthrwx.fsf@localhost> (raw)
In-Reply-To: <jwv4julljaq.fsf-monnier+emacs@gnu.org>

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>



  reply	other threads:[~2022-11-27  5:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 14:40 Delegating user-reserved key binding space definition to users Psionic K
2022-11-21 19:37 ` Stefan Monnier
2022-11-22  2:07   ` Phil Sainty
2022-11-25  2:48     ` Psionic K
2022-11-25  3:31       ` Ihor Radchenko
2022-11-25 13:53         ` xenodasein--- via Emacs development discussions.
2022-11-25 15:16       ` Stefan Monnier
2022-11-26  6:44         ` Ihor Radchenko
2022-11-26 17:29           ` Stefan Monnier
2022-11-27  5:45             ` Ihor Radchenko [this message]
2022-11-27 11:26               ` Psionic K
2022-11-27 11:53                 ` Psionic K
2022-11-28 18:15               ` Stefan Monnier
2022-11-28 18:37                 ` Eli Zaretskii
2022-11-29  2:38                 ` Psionic K
2022-11-29  4:01                   ` Stefan Monnier
2022-11-29  5:22                     ` Psionic K
2022-11-29 13:03                       ` Eli Zaretskii
2022-11-30  6:23                         ` Psionic K
2022-11-30  9:01                           ` xenodasein--- via Emacs development discussions.
2022-11-30 13:44                           ` Eli Zaretskii
2022-11-29 11:54                 ` John Yates

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7sthrwx.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=psionik@positron.solutions \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).