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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Nov 01, 2018 at 20:15:41 +0200, Eli Zaretskii wrote:
> > Date: Thu, 1 Nov 2018 10:00:56 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: 33201@debbugs.gnu.org

> > > > This fix could probably be backported to the emacs-26 branch, but how
> > > > important is it?  What were you actually trying to do when you uncovered
> > > > this bug?

> > > I don't remember.  I have encountered this error multiple times before
> > > and given up debugging something.  Since one generally runs into bugs
> > > when doing work (that is not hacking on Emacs itself), it's helpful to
> > > be able to debug with minimal obstruction, otherwise it becomes an
> > > unjustifiable distraction from the main task.

> > OK, it sounds like it's a major problem.

> It does?  Why?

Well, it's a major problem for the OP, at the very least.  ;-)

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.]

> > @Gemini: The patch below is a (small) portion of
> > e09120d68694272ea5efbe13b16936b4382389d8 from 2018-06-19, the commit that
> > introduced Backtrace Mode.  Can you see anything against applying this
> > commit to the emacs-26 branch to fix this bug?

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

OK.  How about me doing a simpler, but less lazy fix which would just
add handling of `closure' into the existing cond form?

-- 
Alan Mackenzie (Nuremberg, Germany).