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 #11 received at 65620 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Alan Mackenzie <acm <at> muc.de>, 65620 <at> debbugs.gnu.org
Subject: Re: bug#65620: void function edebug-after
Date: Thu, 31 Aug 2023 09:55:18 +0200
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Alan Mackenzie <acm <at> muc.de> writes:
>
>> (defmacro hash-if (condition then-form &rest else-forms)
>>   "A conditional compilation macro analogous to C's #if.
>> Evaluate CONDITION at macro-expansion time.  If it is non-nil,
>> expand the macro to THEN-FORM.  Otherwise expand it to ELSE-FORMS
>> enclosed in a `progn' form.  ELSE-FORMS may be empty."
>>   (declare (indent 2)
>>            (debug (form sexp &rest sexp)))
>>   (if (eval condition lexical-binding)
>>       then-form
>>     (cons 'progn else-forms)))
>
> Dunno if someone is able to fix this (I'm not).  Until then using
> `def-form` `or `sexp` instead of `form` works in a better way (the
> former edebugs CONDITION when instrumenting, the latter would omit
> edebugging the CONDITION entirely).
>
> Anyway, the key point in the above example is that macroexpanding (while
> instrumenting) combined with the `eval' call seems to lead to the
> evaluation of instrumented code outside of an Edebug session when
> CONDITION is instrumented using `form`.  `eval-when-compile' uses
> `def-form` for example - I guess using `form` in this case doesn't work
> as one might expect.

I think what's happening here is like this:

By using 'form' for condition, we're telling edebug to instruments it.
That is, the argument eval sees when foo is instrumented is whatever
edebug wraps around the condition (< ...), and that contains the
eval-after.  Using sexp for the condition doesn't instrument the condition.

One can follow that in the backtrace.

So, I guess there's nothing to fix here.




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.