bug#33201: 26.1; Edebug doesn't work on closures with edebug-unwrap-results

[Gemini Lasswell <gazally@runbox.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alan Mackenzie <acm@muc.de>
>> It seems like in Emacs 26.1 edebug can't be reliably used with
>> edebug-unwrap-results non-nil because there's always a chance it will
>> encounter the symbol `closure', at which point it errors out.
>> [`closure' is wierd, because it has a meaning, yet has none of a
>> function, a value, a property list.]
>
> I understand, but why does this make it a "major" problem?  The only
> major problem in Edebug I could understand is if Edebug could not be
> used at all in some popular situation.  FWIW, I never set
> edebug-unwrap-results non-nil, and I'm a happy "Edebugger".
>
I agree with Eli that this is not a major problem.  I suggest
we close it as fixed in 27.1.

Allen, unless you are doing the kind of debugging described in the
docstring for 'edebug-unwrap-results', meaning debugging a macro where
the results of expressions might include Edebug instrumentation, just
leave it set to nil.

Even if you are doing that kind of debugging, first try it without
setting 'edebug-unwrap-results' non-nil, because if things are going
wrong with the Edebug instrumentation because the debug spec for the
macro is incorrect, which is the most common problem with Edebug and
macros, then having Edebug unwrap the results will make it harder to
figure out what the bug is.

>> > I can: it's quite complex, and even includes gratuitous refactoring of
>> > 'cond' as 'pcase'.

When I have to dig several levels deep in a Lisp expression, I prefer to
use pcase instead of expressions like "(nthcdr 2 (nth 1 (nth 3 sexp)))"
but I can see that it is a matter of taste.

>> OK.  How about me doing a simpler, but less lazy fix which would just
>> add handling of `closure' into the existing cond form?
>
> That's one thing; the other is why do we need to change edebug-unwrap1
> as well?  AFAIU, that takes care of a separate issue, right?

The problem isn't only closures, it's that edebug-unwrap* in emacs-26
doesn't handle dotted forms.  For example, evaluating:

(edebug-unwrap* '(setq foo '(1 . 1)))

or trying to step through this with Edebug with edebug-unwrap-results
set non-nil:

(defmacro my-macro (arg)
  (let ((foo '(1 . 1)))
    `(setq ,arg ',foo)))

will result in: (wrong-type-argument listp 1)

The reason I rewrote edebug-unwrap* was to make it robust enough to
handle anything it might find in backtrace frames, including dotted
forms and circular data structures, so that I could use it to make working
*Backtrace* buffers for Edebug that defaulted to not showing the
instrumentation but let you toggle its visibility.  Making
edebug-unwrap-results work in more situations was a side effect.