> >> Is there a better way to make sure that <return> always falls through >> to the current mode's binding, instead of evil-ret? > > AFAIK no. The problem is that you have to remove the binding from the > containing keymap, but this is the global evil-motion-state-map in > this case. But I think it is an important issue. > > There are several ways to tackle this problem. First one could define > a special symbol (function), say 'evil-undefine, which could be bound > to some key with the effect that it resends the key sequence that > invoked it but with all evil keymaps disabled, e.g., something like > (untested) > > (defun evil-undefine () > (interactive) > (let (evil-mode-map-alist) > (call-interactively (key-binding (this-command-keys))))) > > and then > > (evil-declare-key 'motion completion-list-mode-map "RET" 'evil-undefine) > > The downside is that C-h k for those keys will return 'evil-undefine > instead of the original key-binding (but one could advise > `key-binding' as well). > > A second approach would be to modify `evil-define-key' so that it > automatically inserts the original key-binding, i.e., when enabling > the associated auxiliary keymap all occurences of 'evil-undefine are > replaced (permanently) by the original key-binding. So this variant > would the same as you do in your .emacs file automatically. The > downside of this approach would be that a subsequent modification of > the original keybinding (in the original keymap) would not be > reflected by the auxiliary keymap and thus not be respected. > > Perhaps there are other options, we're open for suggestions.
In terms of documenting the original binding: autopair.el has fallback functionality with documentation; I haven't looked at the code closely enough to understand exactly how it works, but it might be worth considering. See http://autopair.googlecode.com/svn/trunk/autopair.el -- in particular, the definition of autopair-document-bindings. --Leo _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
