all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Psionic K <psionik@positron.solutions>
To: Emacs developers <emacs-devel@gnu.org>
Subject: Delegating user-reserved key binding space definition to users
Date: Mon, 21 Nov 2022 08:40:58 -0600	[thread overview]
Message-ID: <CADQMGARU64KQ=ve=_MbYdtMz0=_SvoxeRbkvNkwCOsbTkt=6kA@mail.gmail.com> (raw)

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

The purpose of this email is to identify if a package should be created or
if the technical implementation requires modification to Emacs.

The motivating problem was to eliminate the possibility of Emacs defaults
or packages creating many bindings sequences in two primary categories:

   - Multiple modifiers such as M-S-* or long sequences such as C-* C-* *.
   M-? is also an example of what I consider to require multiple-modifiers on
   a US key layout where '?' requires shift.
   - High-value space such as M-* and C-*

In order to enforce this choice, the user needs control over the effects of
all calls to create bindings, from an early phase and then persistently
through startup and future package loading.  The user needs a way to
express, in the same dimensions as the implementation, which keys should
receive no-op bindings if not explicitly created by the user.  A
complementary set of functions should allow the user to then make bindings
into the protected keyspace, free from any potential interference.

I was asked to relay my opinion that Emacs should ship with bindings not
much more densely populated than nano.  Nano does not have commands, so
Emacs needs M-x, for example.

It was suggested that advice might work for implementation, up to a point,
since define-key doesn't have a dedicated code of some type I'm unaware of.

The suggestion was made to live with emulation mode maps or even terminal
overriding maps.  I have two concerns about this technically.  Such a
solution provides no consultative feedback, a blind solution.  Second, it
doesn't help users who are already leaning on such maps for modal editing.

My personal preference is to find a path to a mostly complete
implementation as an independent package in order to figure out the problem
better, gaining the breadth of information necessary through incremental
adoption.

I am intending to explore a simple advice of define-key.  My implementation
will no-op any request to bind a command to a key sequence that doesn't
pass a predicate list.  Optionally a report will be stored about which
command bindings were no-op'd and by which filter predicate.  Support for
command and key translation inside of predicates would be my next feature.

If there are multiple key mechanisms I need to intercept, an enumeration of
them will be greatly appreciated.

-- 

Psionic K <psionik@positron.solutions>
Software Engineer

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

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

             reply	other threads:[~2022-11-21 14:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 14:40 Psionic K [this message]
2022-11-21 19:37 ` Delegating user-reserved key binding space definition to users 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
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

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

  git send-email \
    --in-reply-to='CADQMGARU64KQ=ve=_MbYdtMz0=_SvoxeRbkvNkwCOsbTkt=6kA@mail.gmail.com' \
    --to=psionik@positron.solutions \
    --cc=emacs-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.