T, t, F, f operators crash into debugger

[Óscar Fuentes]

David Nebauer <davidnebauer3 at bigpond.com> writes:

> When vim operators T, t, F and f fail in vim because the target cannot 
> be found, it triggers an error which sounds a bell, but otherwise does 
> not interrupt editing.
>
> In evil, on the other hand, when T, T, F and f operators fail in evil 
> they cause the debugger to open in another buffer with the lisp error 
> "Can't find X" where X is the target character.
>
> To an emacs/evil newcomer like me it seems a predictable error like this 
> should not cause code execution to crash and invoke the debugger. My 
> naive suggestion would be that it should indicate an error (perhaps 
> using the system bell or returning an error message in the minibuffer) 
> but continue running without crashing in to the debugger.
>
> I accept that it takes only the press of the 'q' button to close the 
> debugger and return to editing. Nonetheless, that is one button more 
> than vim. Further, because I associate the debugger with a program 
> crash, every time T, t, F or f fail in evil I am briefly jarred out of 
> my editing mindset.
>
> Is there any way to prevent a failed F, f, T or t operation from 
> crashing and invoking the debugger?

In Emacs, do

   C-h v debug-on-error [ENTER]

It should open a new window and, near the top, display this:

   Its value is nil

My bet is that your's will show

   Its value is t

This is what causes the debugger to pop out. Try

   M-x set-variable [ENTER] debug-on-error [ENTER] nil [ENTER]

and see if that fixes the problem. That's a temporary fix. For the
definitive one, you need to locate the place where debug-on-error is set
to t on your configuration files (or maybe you are using a rogue
package.)