I got someone ask this question:

How can I prevent errors that should really just be a bell or flashing screen not open a window with an error?

  • What sorts of errors are you looking to prevent from opening a new window? All errors? Just some? – zck Oct 24 '14 at 2:54
  • @zck I think he wanted to disable all kinds of error buffers from being opened in Emacs. – Tu Do Oct 24 '14 at 2:55

Not exactly sure what the context is or what you mean.

If by "open a window with an error" and "opening error buffer" you mean opening the debugger in buffer *Backtrace*, then set variable debug-on-error to nil to prevent that. The error message will then simply be shown in the echo area.

Variable visible-bell controls whether a bell (ding) sound is heard or the frame is flashed ("visible bell").

| improve this answer | |
  • Thanks. debug-on-error should be nil by default. But I don't know in what context it pops up for him. semantic-mode still pops backtrace, even if debug-on-error is nil; maybe this is the case, or some other packages do this. visible-bell seems only to flash frame, but ring-bell-function controls how to ring the bell. – Tu Do Oct 24 '14 at 4:07
  • visible-bell controls whether function ding rings the bell or flashes the frame. – Drew Oct 24 '14 at 4:09
  • debug-on-error is nil by default, of course. But it being non-nil is likely what is invoking the debugger on an error. And it is of course possible to invoke the debugger (*Backtrace*) explicitly, either related to an error or not. As far as I know, you cannot prevent code from opening the debugger. You can, however, prevent it from automatically opening on an error that is not handled, using nil debug-on-error. – Drew Oct 24 '14 at 4:16
  • @TuDo it seems like you don't exactly know what the error the user wants to stop is. It might be useful to figure that out -- if it's just one package ("when I compile c code, I'd like errors in the minibuffer"), then we can look at that package to figure out what to do. – zck Oct 24 '14 at 4:31
  • @zck: +1. And non-nil debug-on-error is typically a good way to find out what the error is and where it is being called. ;-) – Drew Oct 24 '14 at 4:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.