GNU bug report logs - #54074
29.0.50; Feature request emacs keymap-set and minor-modes

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ergus <spacibba <at> aol.com>, 54074 <at> debbugs.gnu.org
Subject: bug#54074: 29.0.50; Feature request emacs keymap-set and minor-modes
Date: Tue, 22 Feb 2022 09:07:02 -0500

Lars Ingebrigtsen [2022-02-22 14:22:49] wrote:
> Stefan Monnier <monnier <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.