strange behaviour with f, r and t in evil mode: next key is taken as being a command in normal mode

Thu Jun 13 21:35:36 CEST 2013

Hello,

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.

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xFFFCF67D
: in Emacs 24.3.50.1 + Ma Gnus v0.8 + evil 1.0.5
: BBDB version 3.02 ($Date: 2013/05/15 13:17:58 $)