bug#54074: 29.0.50; Feature request emacs keymap-set and minor-modes

[Stefan Monnier]

Lars Ingebrigtsen [2022-02-22 14:22:49] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I'm not sure I understand the use case.  Isn't the way to do this just
>>> to have my-mode add itself to isearch-mode-hook, and then have my-mode
>>> have a minor mode keymap with the prefix it uses?
>> I think the use case is basically any minor mode which currently uses
>> `define-key` in its body to modify some other package's keymap.
> But why do that instead of using a minor mode?

[ I assume you meant "using a minor mode MAP".  ]

E.g. because they don't want the priority that comes with minor mode maps?

> I think many cases where packages do this, it's because the idea
> didn't really occur to the people that did the implementation.

Many, maybe, but definitely not all.

BTW, we currently have related functions to add/remove a keymap from
another: `internal-push/pop-keymap` used by `set-transient-map`.

>> The minor mode can then add/remove a function from the list, and just as
>> is the case with `add-hook`, `add-function`, etc... it will correctly
>> handle the case where the additions/removals are not nested.
> My feeling is that this would be both too complicated for most people
> writing modes, and it would be really confusing for us people that have
> to try to figure out what's actually going on, and finally, values in
> Emacs Lisp are mutable, so it won't work reliably anyway.

W.r.t complexity, it's a worry, indeed.  Until someone implements it and
tries to provide convenient ways to use it (e.g. for minor modes), it's
hard to tell.

W.r.t it being unreliable, it shouldn't be any less reliable than what we
have today, and more importantly any misbehavior could then be fixed by
making the relevant code(s) use the new API, whereas currently there's
basically no way to fix those problems (short of ad-hoc hacks).


        Stefan