bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Ergus
Subject: 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@gnus.org> 
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.
>
>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.




reply via email to

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