f is no longer working as a motion key

[geo7]

Problem

Currently f isn't working as a motion key, and gives the error message :

f is undefined

This is on commit:

commit b29f1a5af90062caef6505c6e9ca626baa1a8c22
Author: justbur <justin@burkett.cc>
Date:   Thu Aug 27 08:58:24 2015 -0400

With all packages updated (might be the problem)

Temporary Solution... ?

I've added the layer evil-snipe with the following settings from @Devagamster in my .spacemacs config file

   dotspacemacs-configuration-layers
   '(
     evil-snipe
     )

And -

(defun dotspacemacs/init ()
  "Initialization function. This function is called at the very
startup of Spacemacs initialization before layers configuration."

  ;; evil-snipe conig settings
  (setq evil-snipe-repeat-keys t)
  (setq evil-snipe-override-mode 1)
  (setq evil-snipe-scope 'buffer)
  (setq evil-snipe-repeat-scope 'buffer)
  (setq evil-snipe-smart-case t)
  (setq evil-snipe-auto-scroll t)
  )

Provides similar functionality to regular f usage

This package provides familiar usage of f, t and F keys, but there are
other options as well (see the help in SPC f e h then evil-snipe then RET
for more info)

Issue with f no longer inputting text after adding this package

This might not be unrelated, but immediately after installing this layer
I was unable to insert the char f. Restarting Spacemacs fixed this for me.

[bgamari]

I have also seen similar symptoms regarding the f key, particularly in the minibuffer.

[zilongshanren]

I also met this issue. I disabled the evil-escape and the problem is gone.

[srid]

f is not working for me even when using master branch (currently on v0.103.6).

[robbyoconnor]

@geo7 SPC h d s now gives the commit hash which you are at, in addition to the branch :P

[syl20bnr]

I encountered the bug yesterday, there are two variants, fd does not work in normal state or f does not work in insert state.
For now I don't know what is triggering this, it happens randomly while in a session, it even fixes itself sometimes. Really weird.

[syl20bnr]

It was due to the fixed lazy loading of evil-iedit-state in develop branch, it caused a bug in evil-escape. It is fixed upstream, it should be available from MELPA in a few hours.

For those having the issue in master, please open a new issue as it should be another issue. Thank you!

[syl20bnr]

Reopening, I let @geo7 close the issue if it is fixed for him.

[syl20bnr]

It is now available on MELPA.

[syl20bnr]

I rewrote from scratch evil-escape (v3.0), it is a lot more clean and the previous limitations are all gone (can be used in macros, no restriction on the first key of the sequence).
Will be available in MELPA soon.

[StreakyCobra]

As it has been fixed upstream long time ago, it should have been corrected in all installations by now. I close this issue, but keep the Fixed upstream label though.