bug#4093: Overlay keymap and timers

[Mihai Bazon]

Indeed, that function looks frightening.

It's worth noting that XEmacs doesn't have this problem.
But the code differs drastically..  Hard to figure out a simple fix.

-M

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> > Yes, this is a really bad thing - sometimes, ie when you need to do
> >> > just that.
> >> The code in keyboard.c reads the set of active keymaps before reading
> >> the next event.  That's most likely the explanation for this behavior.
> > What you are saying does actually make sense.  If it set the keymap
> > *before* serving an event, it should work fine.  But I think what
> > happens is that it sets the keymap *after* executing an event...
> 
> > I looked at the code but couldn't figure out where is the keymap
> > computed.  Could you point it out?
> 
> The relevant code is in .... read_key_sequence! (only those who've had
> to deal with this function understand the "....").
> 
> You'll see that it first collects all the active keyamps (see where it
> calls current_minor_maps), and later on calls read_char (which can do
> redisplay, run timers, run process filters, etc...).
> 
> Basically the problem in the case of changing the keymap from a timer
> comes down to:
> 
>   what happens if the use presses C-c, then your code runs then the user
>   presses C-d:  should the C-c C-d be looked up in the original keymaps
>   or in the new keymaps?
> 
> you worry about the case where the timer is run before the C-c, but from
> Emacs's current point of view, it's no different whether the timer is
> run after 1 key-press, or after 2 key-presses, or after 0 key-presses.
> 
> We can probably change the code to collect the list of active keymaps
> later (e.g. right after the first key-press).
> But maybe an alternative is to provide some way for your Elisp code to
> cause a jump back to `replay_sequence' so that you can force the C-c C-d
> to be interpreted in the new keymaps even if the C-c had already been
> pressed when your code was run.
> 
> In any case, this function is a monster, so I'll only consider changes
> to it if it makes it simpler (typically by moving code out of it into
> some new function).  Maybe the idea of a new "need-to-replay-sequence"
> variable could be a good way to simplify the code: we could maybe
> arrange for most other "goto replay_sequence" to use this new var
> (i.e. replace the current code that checks some relevant condition, by
> some piece of code elsewhere (where that condition is created) which
> sets the var).
> 
> 
>         Stefan