bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Helmut Eller]

Starting Emacs with:

  emacs -Q -nw \
      -eval '(setq debug-on-error t)' \
      -eval '(insert "(defun f () (push))")' \
      -f eval-buffer

only prints this message: 

  Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 0)

This is not what I expect; Emacs should enter the debugger instead.
If "(defun f () (push))" is replaced by "(/ 1 0)" then the
debugger pops up as expected.


In GNU Emacs 24.4.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2014-07-30 on ix
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:	Debian GNU/Linux 7.1 (wheezy)

Configured using:
 `configure --with-jpeg=no --with-gif=no --with-tiff=no'

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Stefan Monnier]

> Starting Emacs with:
>   emacs -Q -nw \
>       -eval '(setq debug-on-error t)' \
>       -eval '(insert "(defun f () (push))")' \
>       -f eval-buffer

> only prints this message: 

>   Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 0)

> This is not what I expect; Emacs should enter the debugger instead.

The eager-macroexpansion is not indispensable (so far), so any errors
that happen during it are demoted to mere warnings (like the line you
quote above).  Hence debug-on-error doesn't cause you to get
a backtrace.  You'd need to use debug-on-signal for that.

But you should indeed be dropped into the debugger if/when you call `f'
(unless you redefine `push' to accept 0 arguments before you call `f',
obviously).

> If "(defun f () (push))" is replaced by "(/ 1 0)" then the
> debugger pops up as expected.

Of course.  Note that when (defun f () (push)) is evaluated, it just
defines `f' but doesn't actually run `push' (tho eager-macroexpansion
tries to macroexpand `push' in the hope to avoid having to do it
every time `f' gets called).


        Stefan

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Helmut Eller]

On Wed, Aug 06 2014, Stefan Monnier wrote:

>> only prints this message: 
>
>>   Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 0)
>
>> This is not what I expect; Emacs should enter the debugger instead.
>
> The eager-macroexpansion is not indispensable (so far), so any errors
> that happen during it are demoted to mere warnings (like the line you
> quote above).

I see, but the message "Eager macro-expansion failure" doesn't sound
like a warning to me.  Maybe use the word "warning" somewhere to avoid
confusion.

> Hence debug-on-error doesn't cause you to get
> a backtrace.  You'd need to use debug-on-signal for that.

The message contains no line number or any other hint where the source
of the problem is; debug-on-error is no help either.  Maybe it would be
better to get rid of the message entirely.

Helmut

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Stefan Monnier]

> The message contains no line number or any other hint where the source
> of the problem is;

Indeed, the location is sadly not available.  Propagating it to the
message would require a large change.

> debug-on-error is no help either.  Maybe it would be
> better to get rid of the message entirely.

No: the warning is intended to turn into an error in some
undecided future version, so we want people to be aware of the problem
and fix their code accordingly.


        Stefan

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> debug-on-error is no help either.  Maybe it would be
>> better to get rid of the message entirely.
>
> No: the warning is intended to turn into an error in some
> undecided future version, so we want people to be aware of the problem
> and fix their code accordingly.

This was seven years ago -- should we start erroring about this now?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> debug-on-error is no help either.  Maybe it would be
>>> better to get rid of the message entirely.
>>
>> No: the warning is intended to turn into an error in some
>> undecided future version, so we want people to be aware of the problem
>> and fix their code accordingly.
>
> This was seven years ago -- should we start erroring about this now?

Another year has passed.  I say let's go ahead and do it.

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> This was seven years ago -- should we start erroring about this now?
>
> Another year has passed.  I say let's go ahead and do it.

Eli, what do you think?

I can't recall seeing these messages lately except when there's a real
error somewhere, so erroring out is usually better, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Helmut Eller <eller.helmut@gmail.com>,  18154@debbugs.gnu.org,  Stefan
>  Monnier <monnier@iro.umontreal.ca>, "'Eli Zaretskii'" <eliz@gnu.org>
> Date: Thu, 30 Jun 2022 11:13:11 +0200
> 
> Stefan Kangas <stefan@marxist.se> writes:
> 
> >> This was seven years ago -- should we start erroring about this now?
> >
> > Another year has passed.  I say let's go ahead and do it.
> 
> Eli, what do you think?
> 
> I can't recall seeing these messages lately except when there's a real
> error somewhere, so erroring out is usually better, I think.

We could try -- if that causes too much trouble, reverting should be
easy enough.

bug#18154: 24.4.50; eval-buffer ignores debug-on-error sometimes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> We could try -- if that causes too much trouble, reverting should be
> easy enough.

OK; now done.  Don't see any problems so far during normal usage...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no