scrolling bug; fall-through keys
Leo Alekseyev
dnquark at gmail.com
Wed Jan 11 09:59:11 CET 2012
>
>> 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
More information about the implementations-list
mailing list