GNU bug report logs - #65620
void function edebug-after

Previous Next

Full log

Message #43 received at 65620-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, acm <at> muc.de,
 65620-done <at> debbugs.gnu.org
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 <at> 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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.