Re: [PATCH] Let input queue deal gracefully with up-events

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> How else would you want to call the key release from a piano keyboard?
>> It is basically auxiliary information that can often be discarded: the
>> key press event is much more important when using a piano keyboard.
>
> I see, that makes sense.

Well, at least there does not seem to be much of a point of Emacs having
only half-baked support of "up-" with optional segfaults when the event
queue is writeable for program-generated events.  While I want to add
native Midi support eventually (it will make the timing info have much
less jitter and should make portability to Windows etc easier), this
would require the same sort of changes anyway, and so will other
attempts at playing with synthetic key events.

Discarding unbound up-events without error like down-events are
currently discarded is, of course, a somewhat arbitrary design decision.
However, if up-xxx is a modified version of xxx, chances are that its
state is comparable to down-xxx.

For Midi, I am still vacillating between using xxx/up-xxx or
down-xxx/up-xxx.  The former (where an unbound xxx leads to a complaint
and an unbound up-xxx is silently discarded) actually corresponds pretty
well with the normal semantics expected from a keyboard and would
probably also operate nicer in connection with M-x local-set-key RET.

My first approach was not messing with Emacs current modifier handling
at all and using xxx-down for keypress and xxx for keyrelease.  But that
was not really satisfactory since then M-x local-set-key RET binds the
keyrelease if you press a key.

Pre-stuffing the modifier caches is also only half-satisfactory since if
you then press a piano key, type C-x @ m and release the key again,
Emacs will still emacs_abort (since the modifier cache was not
pre-filled for M-up-xxx).

So at least in the long run, I think it makes good sense to make the
keyboard-queue backend not complain about data that could not have
originated from the keyboard-queue frontend.  It's not like the crashes
and inconsistencies serve any useful purpose.

Arguably, even if some problem is caused by unexpected things happening
in the keyboard-queue frontend, you may be better served with the
keyboard-queue backend delivering a quite descriptive and printable
strange event rather than crashing: after all, the actual program
location that could have _generated_ the data is no longer connected
with the call stack when emacs_abort is called.

-- 
David Kastrup