unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Delegating user-reserved key binding space definition to users
@ 2022-11-21 14:40 Psionic K
  2022-11-21 19:37 ` Stefan Monnier
  0 siblings, 1 reply; 22+ messages in thread
From: Psionic K @ 2022-11-21 14:40 UTC (permalink / raw)
  To: Emacs developers

[-- 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 --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2022-11-30 13:44 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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