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

[Ergus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On Sun, Feb 20, 2022 at 08:39:16PM +0100, Lars Ingebrigtsen wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Recently I have seen that many packages have a pattern where a global
>> minor mode adds a set of keybindings to another (like isearch or
>> minibuffer). The issue comes when they want to disable the mode, because
>> sometimes they need to iterate or loop over, and then emacs looses the
>> previous binding unless they also adds more code to remember it when set
>> and then bring it back when unset.

Hi Lars.. thanks for replying!

>
>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?
>
Yes this is actually the common way to do it, but it is cumbersome with
no reason for simpler cases... and when more than one keymap can be
affected.

Basically I mean to have a way to add an entry: (keymap …) to another...

Because from the manual:

"If an element of a keymap is itself a keymap, it counts as if this inner
keymap were inlined in the outer keymap."

So, simpler cleaner and eventually not needing execute or start a mode
every time in a hook...

Now keymap-set allows to add a command or keymap to a prefix in another,
but not just append a keymap as is with no prefix and then remove it
completely in a clean way...


>> Something similar happens to some variables that are modified in minor
>> modes and then should be restored... this forces sometimes to restart
>> emacs... (for example completion-styles in fido-mode or some hooks that
>> are always added and then need to be removed... all these is very
>> mechanic and increases code and sources of errors...).
>>
>> The best approach for this one is to save the original value in an alist
>> and assign with a wrapper around setq...  and use a loop when disabling
>> the mode to restore the original values.... it is not perfect, but works
>> in many cases...
>
>I don't think there's any general mechanism that's possible for this.
>Any package may mogrify any variable (destructively or not), and only
>the package can know what it has to do to bring things back to normal
>when the package is switched off.
>

The common is just to save and the restore... isn't it the typical idea
behind a mode? Right now the modes cleanup is a source of issues and
code replication here and there for many mechanical thinks like
add-hook/remove-hook, set variable, unset them, and so on... when the
general idea is that all that may follow the same philosophy than
keybindings set-unset...

Best,
Ergus