bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#4093: Overlay keymap and timers


From: Stefan Monnier
Subject: bug#4093: Overlay keymap and timers
Date: Mon, 10 Aug 2009 12:25:30 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

>> > 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]