Richard Stallman <rms@gnu.org> writes:

> The whole point of unread-post-input-method-events is to be processed
> first.  Changing it to operate last will break it.  When an input method
> runs and generates a sequence of several events, those events must
> be processed before whatever is in unread-command-events.

Ok, seems reasonable ;-)

> One way to fix it is for sit_for to test these variables directly
> so that it doesn't need to change them.  Does anyone see a problem
> with that?

Does it mean that sit-for will have to do active wait [1] ? I think
it's not a good way to go, or have we an alternative?

In a first place, I thought that `read-char' could store the var from
which the char read has been taken, so that a function `putback-char'
could but it back in the good list.  How about that ?

However,  I've   always  dreamt  about  an  unique   entry  point  for
unread-events: unread-command-events would  store direct events (u-c-e
= '(?a ?b))  or events as a cons, the cdr  telling if input-method has
to be used (u-c-e = '(?a (?b . nil) ?c)). Does it seems crazy? [2]

Footnotes: 
[1]  (while (not (or unread-command-events unread-*))
        )

[2]  Of course, _after_ the release ;-)

-- 
 |      Michaël `Micha' Cadilhac   |  La culture c'est comme la confiture,  |
 |         Epita/LRDE Promo 2007   |      c'est meilleur avec du pain.      |
 | http://www.lrde.org/~cadilh_m   |           -- MOI59                     |
 `--  -   JID: micha@amessage.be --'                                   -  --'