debug-ignored-errors usage

debug-ignored-errors usage

[Budi]

How's the usage of debug-ignored-errors ?
I've tried with no benefit whatsoever;

(setq debug-ignored-errors (beginning-of-buffer))

Please help me..Thanks in advance.

Re: debug-ignored-errors usage

[Mauro Aranda]

Budi <budikusasi@gmail.com> writes:

> How's the usage of debug-ignored-errors ?
> I've tried with no benefit whatsoever;
>
> (setq debug-ignored-errors (beginning-of-buffer))
>

Not sure what is that you are trying to achieve, but with the
expression you wrote you are setting debug-ignored-errors to the return
value of beginning-of-buffer, which is nil when called like that.  So
you end up not ignoring errors.

The doc string (which you can read by typing
`C-h v debug-ignored-errors RET') says it is a list, and with emacs -Q
its value is:
(beginning-of-line beginning-of-buffer end-of-line end-of-buffer
end-of-file buffer-read-only file-supersession mark-inactive user-error)

This setting is done in the file lisp/bindings.el, so you might want to
take a look at that file to see how it's done.  Also notice
beginning-of-buffer is already an element of debug-ignored-errors.

If you really want to set debug-ignored-errors to only
beginning-of-buffer you can do the following:
(setq debug-ignored-errors '(beginning-of-buffer))

Best regards,
Mauro.

Re: debug-ignored-errors usage

[Emanuel Berg]

Budi wrote:

> How's the usage of debug-ignored-errors ?
> I've tried with no benefit whatsoever;
>
> (setq debug-ignored-errors (beginning-of-buffer))

I also get nothing sensible from this?

I also wonder what this means when I do
`C-h v debug-ignored-errors RET' and it says:

    debug-ignored-errors is a variable defined
    in ‘C source code’.

    Its value is
    ("^No word found to check!$" search-failed beginning-of-line beginning-of-buffer end-of-line end-of-buffer end-of-file buffer-read-only file-supersession mark-inactive user-error)

    Original value was 
    (beginning-of-line beginning-of-buffer end-of-line end-of-buffer end-of-file buffer-read-only file-supersession mark-inactive user-error)

What does it mean the value is X, and the
original value was Y?

I certainly never changed it. I search my
entire code and there isn't a single mention of
`debug-ignored-errors'.

Do packs from [M]ELPA change it or do "the
original value" refer to earlier
Emacs versions?

Or what's going on?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: debug-ignored-errors usage

[Eric Abrahamsen]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Budi wrote:
>
>> How's the usage of debug-ignored-errors ?
>> I've tried with no benefit whatsoever;
>>
>> (setq debug-ignored-errors (beginning-of-buffer))
>
> I also get nothing sensible from this?
>
> I also wonder what this means when I do
> `C-h v debug-ignored-errors RET' and it says:
>
>     debug-ignored-errors is a variable defined
>     in ‘C source code’.
>
>     Its value is
>     ("^No word found to check!$" search-failed beginning-of-line
> beginning-of-buffer end-of-line end-of-buffer end-of-file
> buffer-read-only file-supersession mark-inactive user-error)
>
>     Original value was 
>     (beginning-of-line beginning-of-buffer end-of-line end-of-buffer
> end-of-file buffer-read-only file-supersession mark-inactive
> user-error)
>
> What does it mean the value is X, and the
> original value was Y?
>
> I certainly never changed it. I search my
> entire code and there isn't a single mention of
> `debug-ignored-errors'.
>
> Do packs from [M]ELPA change it or do "the
> original value" refer to earlier
> Emacs versions?
>
> Or what's going on?

The docstring explains it: these are errors that _won't_ trigger the
debugger even if you've toggled debug-on-error t. Either condition
names, or regexps matching error messages.

Original value/changed value simply shows you what the default value
was, and how the current value is different from the default. Your value
looks very much like ispell or some other spelling package has added
it's own regexp in there to skip debugging when it couldn't find a word
to check.

My value has an added regexp "^Exit the snippet first!$", which I'm
guessing was added by yasnippet or the skeleton package or something.

Eric

Re: debug-ignored-errors usage

[Emanuel Berg]

Eric Abrahamsen wrote:

> The docstring explains it: these are errors
> that _won't_ trigger the debugger even if
> you've toggled debug-on-error t.

This

    (/ 1 0)

triggers the error (arith-error) for me but the
second time I do it it just says "Arithmetic
error" in the minibuffer. And the third time
etc ...

So the debugger is only triggered once per
error type? Is this why I never see the
debugger half-window despite not doing anything
to not see it? I just have Emacs on and before
long there aren't any errors I haven't
seen already?

Also, putting beginning-of-buffer in
`debug-ignored-errors' still echoes
"Beginning of buffer" in the minibuffer when
that happens.

So what does it really achieve: you don't get
the debugger window _the first time either_,
but you still get the message every time
like always?

Because perhaps that message is not part of the
actual error? Which, if so, is wierd, because
from the name of the error, and spelling of the
message, it sure sounds like they are a pretty
close match!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: debug-ignored-errors usage

[Emanuel Berg]

Eric Abrahamsen wrote:

> Your value looks very much like ispell or
> some other spelling package has added it's
> own regexp in there to skip debugging when it
> couldn't find a word to check.

But why does ispell produce an error at all, if
it automatically on installation tells Emacs to
ignore it?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: debug-ignored-errors usage

[Eric Abrahamsen]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Eric Abrahamsen wrote:
>
>> The docstring explains it: these are errors
>> that _won't_ trigger the debugger even if
>> you've toggled debug-on-error t.
>
> This
>
>     (/ 1 0)
>
> triggers the error (arith-error) for me but the
> second time I do it it just says "Arithmetic
> error" in the minibuffer. And the third time
> etc ...
>
> So the debugger is only triggered once per
> error type? Is this why I never see the
> debugger half-window despite not doing anything
> to not see it? I just have Emacs on and before
> long there aren't any errors I haven't
> seen already?
>
> Also, putting beginning-of-buffer in
> `debug-ignored-errors' still echoes
> "Beginning of buffer" in the minibuffer when
> that happens.
>
> So what does it really achieve: you don't get
> the debugger window _the first time either_,
> but you still get the message every time
> like always?
>
> Because perhaps that message is not part of the
> actual error? Which, if so, is wierd, because
> from the name of the error, and spelling of the
> message, it sure sounds like they are a pretty
> close match!

It means that if you've run `toggle-debug-on-error', and then one of
those errors occurs, you _won't_ get the debug window popping up, which
normally all errors would do. Some errors are basic enough or common
enough that Emacs assuming you don't need to see a debug window for
them. For instance, beginning-of-buffer. I can toggle debug on error to
t, put point at the beginning of a buffer, and hit backward-char. That's
actually an error, though all you see is the message in the minibuffer.
If the beginning-of-buffer symbol were not in `debug-ignored-errors', it
would pop up a *Debug* window showing me the error backtrace. But
there's really no point in seeing a backtrace for beginning-of-buffer.

Emanuel Berg <moasenwood@zoho.eu> writes:

> Eric Abrahamsen wrote:
>
>> Your value looks very much like ispell or
>> some other spelling package has added it's
>> own regexp in there to skip debugging when it
>> couldn't find a word to check.
>
> But why does ispell produce an error at all, if
> it automatically on installation tells Emacs to
> ignore it?

It just tells Emacs that, even if `debug-on-error' is true, the user
doesn't really need to see the debug window if there's no word to check.
There's no "deeper information" to be gleaned from a backtrace.

Eric

Re: debug-ignored-errors usage

[Emanuel Berg]

Eric Abrahamsen wrote:

> But there's really no point in seeing
> a backtrace for beginning-of-buffer.

I don't see the point in seeing the message in
the echo area either.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: debug-ignored-errors usage

[Eric Abrahamsen]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Eric Abrahamsen wrote:
>
>> But there's really no point in seeing
>> a backtrace for beginning-of-buffer.
>
> I don't see the point in seeing the message in
> the echo area either.

Well neither do I, if it comes to that, but I was just explaining how it
works :)

Re: debug-ignored-errors usage

[Stefan Monnier]

> So the debugger is only triggered once per error type?

That's probably because you're still in the debugger of the first error,
in which case the debugger is temporarily inhibited.

> Also, putting beginning-of-buffer in `debug-ignored-errors' still
> echoes "Beginning of buffer" in the minibuffer when that happens.

Why is that a surprise?
Do you really consider echoing "Beginning of buffer" as "debugging"?

> but you still get the message every time like always?

The error message is there to let the user know about what happened.
The debugger is there so you can go and change the code to avoid the error.

In the case of beginning-of-buffer, the error is usually not due to
a problem in the code, but a problem in the user's action, which is why
it's placed in debug-ignored-errors (there's usually no point entering
the debugger for that condition since it does not reflect a bug that
we'd want to track down).

> I don't see the point in seeing the message in
> the echo area either.

Many/most commands try to make sure that *something* happens in response
to the command, so the user knows that the command was indeed executed.
Echoing is one way to do that when the command wouldn't do
anything else otherwise.


        Stefan

Re: debug-ignored-errors usage

[Emanuel Berg]

Stefan Monnier wrote:

> In the case of beginning-of-buffer, the error
> is usually not due to a problem in the code,
> but a problem in the user's action, which is
> why it's placed in debug-ignored-errors
> (there's usually no point entering the
> debugger for that condition since it does not
> reflect a bug that we'd want to track down).
> [...]
>
> Many/most commands try to make sure that
> *something* happens in response to the
> command, so the user knows that the command
> was indeed executed. Echoing is one way to do
> that when the command wouldn't do anything
> else otherwise.

In a kitchen, if you pull out a drawer, and at
some point it won't come out any longer because
of some small built-in brake flaps or whatever
to prevent it from falling down on the floor if
pulled too far - and all this works, so it
stops in good order - is this a) an error,
b) something that needs to be communicated
explicitly to the kitchen operator, or
c) something else?

IMO the echo area is far too chatty and only
writing this I noticed several messages that
are of no value to me.

To take another example than those mentioned:
"Auto-saving...done" and "Mark set". In what
way(s) do I benefit from seeing them?

-- 
underground experts united
http://user.it.uu.se/~embe8573