[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
From: |
Alan Mackenzie |
Subject: |
bug#33201: 26.1; Edebug doesn't work on closures with edebug-unwrap-results |
Date: |
Thu, 1 Nov 2018 19:59:18 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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).