T, t, F, f operators crash into debugger
ofv at wanadoo.es
Sat Oct 18 12:51:58 CEST 2014
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
More information about the implementations-list