Re: Emacs 23 Mac port

[Stefan Monnier]

>>>>> Thanks.  But then a special event such as SIGUSR1 cancels an
>>>>> incomplete key sequence being typed.  How about doing this only when
>>>>> the current buffer is changed by the special event?
>>>> IIRC the general approach to these kinds of problems in
>>>> read-key-sequence is to only recompute the initial state if the current
>>>> key-sequence is still empty.
>>>> I.e. rather than check whether the special event has changed current
>>>> buffer, we would instead check whether the keybuf is still empty.
>>> But that can be wrong too.  In *scratch*:
>>> C-c<drop .c-file>  C-e
>> In which sense would it be wrong?  What would you consider to be "right"?
> Well, given that we recompute only if the key-sequence is empty, the case
> above will then behave as the original bug.

But it's very different, because the C-c C-e sequence was started in the
*scratch* buffer, so it's not at all obvious that it should be looked up
and run in the new buffer.

> I guess right would be to somehow detect that ketmaps need to be
> recomputed and do so without discarding any ongoing key sequence.

I don't think there is such a thing as "right" for such a case.  So the
only thing that truly matters is that we don't end up looking up the
command in the keymap of buffer A and then running the comand in buffer
B (which would clearly be wrong).  Actually, this should not only be
true of "current-buffer" but of position as well (i.e. if the
special-event-map causes point to move or text to change such that
the keymaps specified by text-propeties change, the same reasoning
applies).

For drag&drop, we could just throw away the partially-started key
sequence, but for SIGUSR1 (more likely to occur without direct user
intervention), this is not a good idea.


        Stefan