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

[Stefan Monnier]

> 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
`sit-for'.


        Stefan