strange behaviour with f, r and t in evil mode: next key is taken as being a command in normal mode
Eric S Fraga
e.fraga at ucl.ac.uk
Thu Jun 13 21:35:36 CEST 2013
I just upgraded both emacs and evil. The latest commit for evil is
| commit 9d0d51ffc4281b2e716618fcdbe52414a81aa7b6
| Author: Michael Markert <markert.michael at googlemail.com>
| Date: Fri Jun 7 11:22:24 2013 +0200
| Move ace-jump-mode integration out of `eval-after-load`.
and emacs is the snapshot from 11 June.
Now, when in normal state, commands like f (evil-find-char), t
(evil-find-char-to) and r (evil-replace) no longer work because the next
keystroke is read as if in normal mode (e.g. typing "f x" causes the
character under the cursor to be deleted).
I can revert evil to an earlier state, of course.
The only commit I see from the previous couple of weeks (since the last
time I pulled from the git repository) that could have something to do
with this (but only because I don't actually understand the commit
message ;-) appears to be:
| commit bcf0bac71c984ea45dc94f283e281f4ffbc5b4a1
| Author: Frank Fischer <frank.fischer at mathematik.tu-chemnitz.de>
| Date: Fri May 24 22:01:11 2013 +0200
| Disable narrowing in char arguments in operator state (fix #294)
| When éa motion is read in operator state, the buffer is narrowed to
| the current field so that the operation is always restricted to that
| field. If a character argument is read then this restriction is
| visible. This fix disables the restriction temporarily if an argument
| with the <C> interactive code is used, which is the case for f,F,t and
| T motions.
The problem arises with emacs -Q and only evil loaded so the problem is
not caused by any customisation I have made, as far as I can tell.
: Eric S Fraga, GnuPG: 0xFFFCF67D
: in Emacs 22.214.171.124 + Ma Gnus v0.8 + evil 1.0.5
: BBDB version 3.02 ($Date: 2013/05/15 13:17:58 $)
More information about the implementations-list