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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Mar 15, 2015 at 04:36:18PM -0400, Stefan Monnier wrote:
> > 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.

Unfortunately, neither did I.  It was garbage.  Sorry for the time
wasted.  I've superseded it with a fix which actually is a fix, I hope.

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

Exactly.  That was the bug.

> 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?

My next post to this bug.  ;-)

> Also, I wonder why the edebug.el code doesn't use the return value of
> `sit-for'.

It does now.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).