David Nebauer <[email protected]> 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.) _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
