bug#65620: closed (void function edebug-after)

[GNU bug Tracking System]

Your message dated Sat, 2 Sep 2023 13:57:38 +0000
with message-id <ZPM_Ut9Dm1RZzzZq@ACM>
and subject line Re: bug#65620: void function edebug-after
has caused the debbugs.gnu.org bug report #65620,
regarding void function edebug-after
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
65620: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65620
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> void function edebug-after
>
>
>
>
> Date: 
>
> Wed, 30 Aug 2023 12:57:29 +0000
>
>
>
>
> Hello, Emacs.
>
> On a recent master branch Emacs:
> (i) emacs -Q
> (ii) Insert the following into *scratch*:
>
> (defmacro hash-if (condition then-form &rest else-forms)
>   "A conditional compilation macro analogous to C's #if.
> Evaluate CONDITION at macro-expansion time.  If it is non-nil,
> expand the macro to THEN-FORM.  Otherwise expand it to ELSE-FORMS
> enclosed in a `progn' form.  ELSE-FORMS may be empty."
>   (declare (indent 2)
>            (debug (form sexp &rest sexp)))
>   (if (eval condition lexical-binding)
>       then-form
>     (cons 'progn else-forms)))
>
> (defun foo (bar)
>   (hash-if (< emacs-major-version 19)
>       (car bar)
>     (cons bar bar)))
>
> (iii) Evaluate hash-if by putting point after it and doing C-x C-e.
> (iv) Attempt to instrument foo for edebug by putting point inside foo and
>   doing C-u C-M-x.  This throws the error: "Ignoring macroexpansion
>   error: (void-function edebug-after)".  This attempt to evaluate
>   edebug-after is a bug.
>
> -- 
> Alan Mackenzie (Nuremberg, Germany).
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#65620: void function edebug-after
>
>
>
>
> Date: 
>
> Sat, 2 Sep 2023 13:57:38 +0000
>
>
>
>
> Hello, Gerd.
>
> On Sat, Sep 02, 2023 at 15:15:55 +0200, Gerd Möllmann wrote:
> > Alan Mackenzie <acm@muc.de> writes:
>
> [ .... ]
>
> > > .... However, edebugging through a function which invoked such a
> > > macro can produce errors.  This is all caused by having a `form'
> > > element in the edebug spec where there should be `sexp'.
>
> > > To try and ameliorate this, I propose adding a sentence to the
> > > description of `sexp' in doc/lispref/edebug.texi:
>
>
> > > diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi
> > > index c5be3a40d2c..a64ebda6803 100644
> > > --- a/doc/lispref/edebug.texi
> > > +++ b/doc/lispref/edebug.texi
> > > @@ -1289,6 +1289,8 @@ Specification List
> > >  @item sexp
> > >  A single unevaluated Lisp object, which is not instrumented.
> > >  @c an "expression" is not necessarily intended for evaluation.
> > > +If the macro evaluates an argument at macro-expansion time, you should
> > > +use @code{sexp} for it, not @code{form}.
>
> > >  @item form
> > >  A single evaluated expression, which is instrumented.  If your macro
>
>
> > Yes, that's helpful.
>
> Thanks!  I've committed the patch to the two files, and I'm now closing
> the bug.
>
> -- 
> Alan Mackenzie (Nuremberg, Germany).
>
>
> --- End Message ---