bug#65620: void function edebug-after

[Gerd Möllmann]

Alan Mackenzie <acm@muc.de> writes:

> 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.  

Ok.

> 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
>

Yes, that's helpful.