1

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?

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

1 Answer 1

Reset to default
5

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
5
  • 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
    Commented Oct 24, 2014 at 4:07
  • visible-bell controls whether function ding rings the bell or flashes the frame.
    – Drew
    Commented Oct 24, 2014 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
    Commented Oct 24, 2014 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
    Commented Oct 24, 2014 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
    Commented Oct 24, 2014 at 4:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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