scrolling bug; fall-through keys
I find that evil-previous-line doesn't behave well with smooth-scrolling (http://www.emacswiki.org/cgi-bin/wiki/SmoothScrolling). That is, if you press "k", when the cursor reaches the top of the window, a new page will appear. It should stop at e.g. 5 lines before window edge and smoothly scroll the text. evil-next-line works as it is supposed to, so I suspect this is a bug of some sort. The second issue I've been wondering about is the following: in my config, I have 14 lines that make sure that <return> in a particular mode does what it was originally bound to, e.g. (evil-declare-key 'motion completion-list-mode-map (kbd "<return>") 'choose-completion) (evil-declare-key 'motion completion-list-mode-map "RET" 'choose-completion) (evil-declare-key 'motion browse-kill-ring-mode-map (kbd "<return>") 'browse-kill-ring-insert-and-quit) (evil-declare-key 'motion browse-kill-ring-mode-map "RET" 'browse-kill-ring-insert-and-quit) Is there a better way to make sure that <return> always falls through to the current mode's binding, instead of evil-ret? --Leo
On Tue, Jan 10, 2012 at 05:04:14PM -0600, Leo Alekseyev wrote:
I find that evil-previous-line doesn't behave well with smooth-scrolling (http://www.emacswiki.org/cgi-bin/wiki/SmoothScrolling). That is, if you press "k", when the cursor reaches the top of the window, a new page will appear. It should stop at e.g. 5 lines before window edge and smoothly scroll the text. evil-next-line works as it is supposed to, so I suspect this is a bug of some sort.
Fixed in 6b7ff12. Although it's probably a bug in smooth-scrolling as it does not handle negative prefix arguments for `previous-line' and `next-line' well (although those are permitted).
The second issue I've been wondering about is the following: in my config, I have 14 lines that make sure that <return> in a particular mode does what it was originally bound to, e.g.
(evil-declare-key 'motion completion-list-mode-map (kbd "<return>") 'choose-completion) (evil-declare-key 'motion completion-list-mode-map "RET" 'choose-completion) (evil-declare-key 'motion browse-kill-ring-mode-map (kbd "<return>") 'browse-kill-ring-insert-and-quit) (evil-declare-key 'motion browse-kill-ring-mode-map "RET" 'browse-kill-ring-insert-and-quit)
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. Frank
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
On Wed, Jan 11, 2012 at 02:59:11AM -0600, Leo Alekseyev wrote:
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.
Yes and exactly this functionality causes some trouble when used in conjunction with auto-complete (auto-complete itself needs special handling for the repeat system - which works quite well unless you also use autopair mode *argh*). That's a really nasty issue I currently have no solution for. And that's really another problem with fallbacks. Frank
participants (2)
-
Frank Fischer -
Leo Alekseyev