T, t, F, f operators crash into debugger
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?
On Sat, Oct 18 2014 (18:03), David Nebauer <[email protected]> wrote:
Is there any way to prevent a failed F, f, T or t operation from crashing and invoking the debugger?
Evil does not start the debugger but signals an error. You have most likely set `debug-on-error' set to non-nil. If you want to keep that you can also just ignore those movement errors: (add-to-list 'debug-ignored-errors "^Can't find .") Michael
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.)
On 18/10/14 20:21, Óscar Fuentes wrote:
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. C-h v debug-on-error [ENTER]
My bet is that your's will show
Its value is t
You are correct. In troubleshooting my startup files I long ago put this in my init.el and never took it out: (add-hook 'after-init-hook '(lambda () (setq debug-on-error t))) Thanks for helping out a newbie.
participants (4)
-
David Nebauer -
Michael Markert -
Stefan Monnier -
Óscar Fuentes