bug#65620: void function edebug-after

[Alan Mackenzie <acm@muc.de>]

Hello again, Gerd.

On Sat, Sep 02, 2023 at 06:27:32 +0200, Gerd Möllmann wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Here's a working patch with a slight improvement: the error message
> > identifies the macro suspected of having an erroneous edebug spec.

> Maybe we could also add to the comment for edebug-before that basically
> any of the instrumented form in the context you describe can lead to
> errors?

> I believe, if IFORM is such an instrumented form, something like

>    (let ((x IFORM))
>      ...)

> in some macro will also error. 

I've not been able to produce an error at macro-exansion time with a
form like that.  So I haven't amended that comment, yet.  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


> Otherwise, LGTM.  Thanks for doing this!

Thanks!  I'm seriously considering committing this soon.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).