Re: read_char() does not detect, handle special-event-map buffer changes

[Stefan Monnier]

> Did you see my comment in the original email?  read_char() is already
> trying to detect changed keymaps.

>       if (current_buffer != prev_buffer)
>         {
>           /* The command may have changed the keymaps.  Pretend there
>              is input in another keyboard and return.  This will
>              recalculate keymaps.  */
>           c = make_number (-2);
>           goto exit;
>         }
>       else
>         goto retry;

> The bug is happening because the test is flawed: current_buffer and
> prev_buffer are the same, so Emacs doesn't think it needs to recalculate
> anything.  It loops back to the top of read_char() and reads another
> character with the same keymap.

I know, but I'm still weary of the possible side-effects.  The change
I was proposing (to delay computation of the set of active keymaps to
after we got the first event) also has the advantage that it is not
specific to special-event-map, so it's desirable in any case.

> This removes a flawed optimization and returns a documented value.

The main issue is that it's not clear what should happen if you switch
buffers in the middle (rather than before the beginning) of
a key sequence.  And I'd rather not have to think about it ;-)

> It doesn't touch read_key_sequence, so that risk goes away.

I've just installed a patch (in trunk) which touches read_key_sequence
intrusively (in case you still had doubts whether I was a masochist).
This should hopefully fix your problem (at least it fixes the
sigusr1-handler test case you sent).  It also cleans up the code a bit.
Hopefully it doesn't introduce too many new problems.


        Stefan