[Vimpulse] Arrow keys don't work as motions
Hi, Typing a special key such as <right> in Operating-Pending mode currently causes Vimpulse to crash in vimpulse-range. I've included a patch that fixes this, so that (for example) y right yanks the character under point, as it does in Vim. However, after fixing this bug there is another problem. Namely, if I type y 2 right (to yank two characters), the keypress parser continues waiting for input so that the echo line reads y 2 right- and it keeps on accepting more input no matter how many times I press right, until I press a non-special-key motion such as $, when it finally runs the command. I couldn't work out what was going on here, so I gave up. The patch for the first bug is below, though. Oh, and thanks for Vimpulse! It's brilliant! Nick diff --git a/vimpulse-operator.el b/vimpulse-operator.el index 4b1f594..b4ff648 100644 --- a/vimpulse-operator.el +++ b/vimpulse-operator.el @@ -220,8 +220,9 @@ (defun vimpulse-range (message oldmsg) ;; With doubled operator ("gqgq" or "gqq"), set motion to current line. (if (or (eq vimpulse-this-motion vimpulse-this-operator) - (member (vimpulse-strip-prefix (this-command-keys) t) - '("g??" "gUU" "gqq" "guu" "gww" "g~~"))) + (member (vimpulse-strip-prefix (this-command-keys)) + (mapcar 'string-to-vector + '("g??" "gUU" "gqq" "guu" "gww" "g~~")))) (setq vimpulse-this-motion 'vimpulse-line) (setq vimpulse-this-motion (vimpulse-operator-remapping vimpulse-this-motion))))
Hi Nick, thanks for the bug report. This should be fixed in commit [9d7095a742]. Vimpulse compares the key sequence as a string against shortcuts like "g??", but not all key sequences can be represented as strings. String conversion can only work if all the elements in the sequence are characters (i.e., integers). If not, we have to use vector format instead. -- Vegard
Hi Vegard, Vegard Øye <[email protected]> writes:
This should be fixed in commit [9d7095a742]. Vimpulse compares the key sequence as a string against shortcuts like "g??", but not all key sequences can be represented as strings. String conversion can only work if all the elements in the sequence are characters (i.e., integers). If not, we have to use vector format instead.
Thanks for the quick response. I also mentioned another problem, that y 2 right didn't work, that I've since managed to fix. The bug was in vimpulse-keypress-parser: there's a variable 'digit that gets set when you type a prefix argument (2 in this case). It's supposed to get reset once you type the next character, but this only happens if the next character is an ASCII character, and as a result if you type in a non-ASCII character it gets accidentally treated as a prefix argument instead. Here is a patch to fix it. Nick diff --git a/vimpulse-operator.el b/vimpulse-operator.el index 178e6cd..27af4d2 100644 --- a/vimpulse-operator.el +++ b/vimpulse-operator.el @@ -350,8 +350,9 @@ (defun vimpulse-keypress-parser (&optional no-remap) (setq char (or (get char 'ascii-character) char)))) ;; This trick from simple.el's `digit-argument' ;; converts keystrokes like C-0 and C-M-1 to digits. - (when (characterp char) - (setq digit (- (logand char ?\177) ?0))) + (if (integerp char) + (setq digit (- (logand char ?\177) ?0)) + (setq digit nil)) (if (keymapp cmd) (setq keys (vconcat keys (vector char))) (setq keys (vector char)))
Nick Smallbone <[email protected]> writes:
diff --git a/vimpulse-operator.el b/vimpulse-operator.el index 178e6cd..27af4d2 100644 --- a/vimpulse-operator.el +++ b/vimpulse-operator.el @@ -350,8 +350,9 @@ (defun vimpulse-keypress-parser (&optional no-remap) (setq char (or (get char 'ascii-character) char)))) ;; This trick from simple.el's `digit-argument' ;; converts keystrokes like C-0 and C-M-1 to digits. - (when (characterp char) - (setq digit (- (logand char ?\177) ?0))) + (if (integerp char) + (setq digit (- (logand char ?\177) ?0)) + (setq digit nil)) (if (keymapp cmd) (setq keys (vconcat keys (vector char))) (setq keys (vector char)))
Is the `characterp' -> `integerp' change really necessary? On XEmacs, (integerp ?\C-0) => nil, although the integer <--> character arithmetic (`-', `logand') works the same as in GNU Emacs. Štěpán
Štěpán Němec <[email protected]> writes:
Is the `characterp' -> `integerp' change really necessary? On XEmacs, (integerp ?\C-0) => nil, although the integer <--> character arithmetic (`-', `logand') works the same as in GNU Emacs.
On GNU Emacs it's the other way round: (characterp ?\C-0) => nil, but (integerp ?\C-0) => t. What if we changed it to use (or (characterp char) (integerp char)) instead? Nick
Nick Smallbone <[email protected]> writes:
Štěpán Němec <[email protected]> writes:
Is the `characterp' -> `integerp' change really necessary? On XEmacs, (integerp ?\C-0) => nil, although the integer <--> character arithmetic (`-', `logand') works the same as in GNU Emacs.
On GNU Emacs it's the other way round: (characterp ?\C-0) => nil, but (integerp ?\C-0) => t. What if we changed it to use (or (characterp char) (integerp char)) instead?
Sounds good. Any reason not to do that, Vegard?
On 2010-09-09 17:21, Štěpán Němec wrote:
Nick Smallbone <[email protected]> writes:
What if we changed it to use (or (characterp char) (integerp char)) instead?
Any reason not to do that, Vegard?
Done in commit e74dd44. -- Vegard
participants (3)
-
Nick Smallbone -
Vegard Øye -
Štěpán Němec