[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two related edebug problems
From: |
Kim F. Storm |
Subject: |
Re: two related edebug problems |
Date: |
Sat, 12 Aug 2006 02:19:36 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
> 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.
We currently have the following "unread event" variables (in order of usage):
unread-post-input-method-events
unread-command-char (obsolete)
unread-command-events
unread-input-method-events
<keyboard macros>
unread_switch_frame (C internal)
At which step should unread-sit-for-event be placed?
I.e. if some timer function actually places something on
unread-command-events, should that be interpreted before or after
unread-sit-for-event ??
BTW, unread-post-input-method-events and unread-input-method-events
have the _same_ doc string:
List of events to be processed as input by input methods.
These events are processed after `unread-command-events', but
before actual keyboard input. */);
According to the sequence in the code, "after" should be "before"
for unread-post-input-method-events.
But the name of these vars puzzles me... since the -post- thing
is actually run _before_ the other vars...??
Maybe the doc strings need some clarification...
--
Kim F. Storm <address@hidden> http://www.cua.dk