[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Severe lossage from unread-command-events
From: |
David Kastrup |
Subject: |
Re: Severe lossage from unread-command-events |
Date: |
Thu, 06 Aug 2015 17:01:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: David Kastrup <address@hidden>
>> 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