[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two related edebug problems
From: |
Chong Yidong |
Subject: |
Re: two related edebug problems |
Date: |
Sat, 12 Aug 2006 00:02:10 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> 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.
- two related edebug problems, Ken Manheimer, 2006/08/07
- Re: two related edebug problems, Richard Stallman, 2006/08/08
- Re: two related edebug problems, Ken Manheimer, 2006/08/08
- Re: two related edebug problems, Chong Yidong, 2006/08/10
- Re: two related edebug problems, Stefan Monnier, 2006/08/11
- Re: two related edebug problems, Kim F. Storm, 2006/08/11
- Re: two related edebug problems, Richard Stallman, 2006/08/12
- Re: two related edebug problems,
Chong Yidong <=
- Re: two related edebug problems, Richard Stallman, 2006/08/12