Re: Severe lossage from unread-command-events

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 05 Aug 2015 17:46:50 +0200
>> 
>> run the included test file using
>> 
>> emacs -Q -l timer-test.el
>> 
>> and then open the generated dribble file /tmp/mydrib.  On my computer,
>> it looks something like
>> 
>> 0000000000000000001111111111111111111222222222222222222223333333333333333444444444444444444555555555555555556666666666666666667777777777777777778888888888888888899999999999999999
>> 
>> which means that of 4000 events having an effect in the scratch buffer,
>> about 5% (a non-deterministic amount) are actually recorded in the
>> dribble file.  In particular, it looks like only the first of several
>> events placed into unread-command-events at one point of time will ever
>> see the dribble file.  While I am only moderately interested in actually
>> generating a useful dribble file, the same holds for macro recording.
>> And I have an actual application which is severely impacted here.
>> 
>> Note that _all_ of the events (usually) are actually processed as input
>> in the *scratch* buffer.  It is only the recording of them which falls
>> really, really flat on its face.
>
> 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.

My test programs used (t . EVENT) after just using EVENT did not do the
trick either.  However, I don't think most of the other uses of
unread-command-events I have seen bother doing so.  It might or might
not be a red herring.

> Does the following naïve attempt at fixing this give good results?  If
> not, can you tell why not, or show a test case where it misbehaves?

I'll be giving it a try.  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.  Or whether the code is in need of reorganization before
one can hope to get it right anyway.

Thanks,

-- 
David Kastrup