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

Previous Next

Full log

Message #11 received at 54074 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54074 <at> debbugs.gnu.org
Subject: Re: bug#54074: 29.0.50; Feature request emacs keymap-set and minor-modes
Date: Sun, 20 Feb 2022 22:18:07 +0100

On February 20, 2022 8:39:16 PM GMT+01:00, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>Ergus <spacibba <at> 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.
>
>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?
>

Actually the mode does not need to be only for isearch-mode... It can be a global mode that adds multiple other stuff + some extra search commands... It only needs to be enabled once... And in general there is not any reason to force it's keys to add an extra prefix...

Adding 1 command to isearch-mode-map is fine... Suppose we need to add 5... Then it is easier to have a map and add it inline to isearch-mode-map...




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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Previous Next

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