Re: two related edebug problems

[storm@cua.dk (Kim F. Storm)]

Stefan Monnier <monnier@iro.umontreal.ca> 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 <storm@cua.dk> http://www.cua.dk