[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
- bug#4093: Overlay keymap and timers, Mihai Bazon, 2009/08/09
- bug#4093: Overlay keymap and timers, Lennart Borgman, 2009/08/09
- bug#4093: Overlay keymap and timers, Mihai Bazon, 2009/08/09
- bug#4093: Overlay keymap and timers, Stefan Monnier, 2009/08/10
- bug#4093: Overlay keymap and timers, Mihai Bazon, 2009/08/10
- bug#4093: Overlay keymap and timers,
Stefan Monnier <=
- bug#4093: Overlay keymap and timers, Lennart Borgman, 2009/08/10
- bug#4093: Overlay keymap and timers, Stefan Monnier, 2009/08/10
- bug#4093: Overlay keymap and timers, Lennart Borgman, 2009/08/10
- bug#4093: Overlay keymap and timers, Stefan Monnier, 2009/08/10
- bug#4093: Overlay keymap and timers, Lennart Borgman, 2009/08/10
- bug#4093: Overlay keymap and timers, Mihai Bazon, 2009/08/10
- bug#4093: Overlay keymap and timers, Mihai Bazon, 2009/08/11
- bug#4093: Overlay keymap and timers, Stefan Monnier, 2009/08/13
- bug#4093: Overlay keymap and timers, Mihai Bazon, 2009/08/13