[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65620: void function edebug-after
From: |
Alan Mackenzie |
Subject: |
bug#65620: void function edebug-after |
Date: |
Sat, 2 Sep 2023 13:10:21 +0000 |
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).