[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20074: edebug tracing can't be stopped with 'S'

From: Stefan Monnier
Subject: bug#20074: edebug tracing can't be stopped with 'S'
Date: Sun, 15 Mar 2015 16:36:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> What is happening is that while tracing, edebug is waiting for an input
> event with "(sit-for 1)".  When you type the "S", sit-for pushes it onto
> `unread-command-events' and returns.  Unfortunately, before calling the
> recursive edit into the edebug command loop, `unread-command-events' gets
> bound to nil, thus edebug doesn't see the "S".  The motivation here is
> probably to separate the "outside" event queue from edebug's event queue.

Hmmm sounds like we indeed have a problem here.

> Here is a fix (which Eli will probably call a workaround ;-).  In trace
> mode, the top event (if any) is pulled off the "outside"
> `unread-command-events' and pushed onto edebug's binding of it.

I don't quite understand your fix.

AFAICT, the sit-for is inside the let-binding, so when we enter the
sit-for, unread-command-events is nil (more or less for sure) because we
just bound it to nil, and when we exit sit-for maybe
unread-command-events is non-nil, but when we then exit the let-binding
we throw away whether was added to unread-command-events.

So I don't understand how changing the entrance to the let-binding fixes
this problem, since it seems that the info gets lost when we exit the
let-binding, rather than it being hidden by the let-binding when we
enter it.

What am I missing?

Also, I wonder why the edebug.el code doesn't use the return value of


reply via email to

[Prev in Thread] Current Thread [Next in Thread]