[Top][All Lists]

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

Re: Enhancements to "minor-mode-map-alist" functionality.

From: Stefan Monnier
Subject: Re: Enhancements to "minor-mode-map-alist" functionality.
Date: Fri, 12 Apr 2002 16:30:08 -0400

> But I still think the use of the minor-mode-overriding-map-alist for
> this purpose is pretty obscure (although I suspect that is the
> purpose for which it was invented...)

I still think it's the best solution so far.
Better than a `keymap' text-property (help-follow also works on non-buttons
and I care about it, since I wrote the code for it ;-).

> > > Also, the keymap lookup code would also have to be careful not to
> > > interpret the FUN part as a binding,
> > 
> > You can force it to be a symbol.
> I would prefer not to do that; an alternative would be to put a
> cons cell (:filter . FORM) into the keymap, causing the rest of
> the keymap to be ignored if FORM returns nil.

Note that if the evaluation is done inside get_keymap then there
is no problem whatsoever and the map can have any shape we want
(the only reason to start it with `keymap' is convenience, for instance).

> I would be much easier if an element in the minor-mode-map-alist
> could be tagged as `keep at head of list'.  IIRC we discussed this
> some time ago on this list, and really didn't find a way to
> accomplish that.

Indeed, it would be easy to do in add-minor-mode and define-minor-mode
or with a watcher, but in the current context, it seems hopeless.
Although you could of course write a general post-command-hook that
does what you want and that both cua and viper could use.

> But maybe such modes could simply put their map on
> minor-mode-overriding-map-alist instead ?  Is that "legal practice"?

I don't think there's anything illegal about it, but since that variable is
automatically made buffer-local, it will also require some care, although
it shouldn't be too bad.


reply via email to

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