Re: Severe lossage from unread-command-events

[Eli Zaretskii <eliz@gnu.org>]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 06 Aug 2015 17:01:52 +0200
> 
> > My reading of the code in read_char is that when we consume events
> > from unread-command-events, we don't always record the events we find
> > there.
> 
> Well, according to how I read the variable description of
> unread-command-events, some are bounced back there from input which has
> already been recorded.  The description reads:
> 
>     Documentation:
>     List of events to be read as the command input.
>     These events are processed first, before actual keyboard input.
>     Events read from this list are not normally added to ‘this-command-keys’,
>     as they will already have been added once as they were read for the
>     first time.
>     An element of the form (t . EVENT) forces EVENT to be added to that list.

This talks about a different kind of "recording", the one that stores
keyboard input in this-command-keys.  My changes don't touch that (at
least I hope they don't ;-)

> The code in keyboard.c is complex to a degree where I do not trust
> myself to venture a guess regarding the nature of the right fix.

I agree.  I originally waited for one of the handful of people who
know their ways inside that function to speak up, but they never did.

To see what's going on, I instrumented the code with special
printouts, and clearly saw that we only record the events that are
taken from unread-command-events in one of two possible places in the
code, where we have fragments such as this one:

  if (CONSP (Vunread_command_events))
    {
      [...]
      c = XCAR (Vunread_command_events);
      Vunread_command_events = XCDR (Vunread_command_events);

One such fragment is at the beginning of read_char, around line 2430
of keyboard.c -- the events taken there are not recorded, because we
jump over the code that records them.  The second such fragment is
around line 2815 of keyboard.c -- the events we take there _are_
recorded by the call to record_char on line 2992.

Now, since your timer fires at very high frequency, many events are
pushed before we see them on line 2815.  We extract only the first
event there, and it is recorded.  The rest are handled by the code at
line 2430, and are not recorded, AFAICS.  My changes cause them to be
recorded, or at least your simple test seems to produce reasonable
results.

> Or whether the code is in need of reorganization before one can hope
> to get it right anyway.

It's next to impossible to reorganize code one doesn't fully
understand, and do a good job.