[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Delegating user-reserved key binding space definition to users

From: Psionic K
Subject: Delegating user-reserved key binding space definition to users
Date: Mon, 21 Nov 2022 08:40:58 -0600

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]