Re: two related edebug problems

[Chong Yidong <cyd@stupidchicken.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Is this really necessary?  It seems to me that code that messes with
unread-command-events should simply take the behavior of sit-for into
account, and avoid breaking it.  I'm not sure this situation arises
often enough to justify introducing a separate unread-command-events
mechanism for sit-for.