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

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Wed, 30 Aug 2023 12:59:02 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #35 received at 65620 <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>, 65620 <at> debbugs.gnu.org
Subject: Re: 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 <at> 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).




This bug report was last modified 1 year and 267 days ago.

Previous Next


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