Re: two related edebug problems

[Richard Stallman <rms@gnu.org>]

    > I found out the cause of the bug.  edebug-display calls sit-for to
    > pause before displaying eval results, then calls
    > edebug-recursive-edit.  However, edebug-recursive-edit rebinds
    > unread-command-events, causing sit-for interruptions (which are put
    > into unread-command-events) to go unnoticed.  This creates problems
    > when you type in edebug commands in quick succession.  I fixed this by
    > moving the rebinding of unread-command-events to edebug-display.

    This is a workaround rather than a fix.  A real fix would be to change
    sit-for so it doesn't use unread-command-events but an internal variable
    instead with which other code can't mess.

I disagree.  unread-command-events is defined to do what it does.  If
Lisp code sets it to nil, that gets rid of the pending events.  If
Lisp code later sets it back to something non-nil, that restores them.
If the result of doing that isn't what you want, you should not do that.