[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33201: 26.1; Edebug doesn't work on closures with edebug-unwrap-resu
bug#33201: 26.1; Edebug doesn't work on closures with edebug-unwrap-results
Fri, 2 Nov 2018 00:13:31 -0700
On Thu, Nov 1, 2018 at 4:07 PM Gemini Lasswell <address@hidden> wrote:
> 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.
I can live with that, especially since the backport sounds non-trivial.
> 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.