bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously))

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]

Hi!

I have narrowed down the possible bzr revision candidates.

By back-applying 111505 into earlier revisions I have concluded that 110812
contains the problem. To ensure that the problem wasn't caused by 111505
itself, I also applied it to 110785 (the last revision without this
problem) without introducing the "key dropped" problem. In other words, the
problem must have been introduced somewhere in the range 110796..110811.

Unfortunately, I get a build error below for these revisions. The build
error is "not enough room for load commands for new __DATA segments", which
is issued from deep inside the "unexmacosx.c" module. I have no insight
into the "unexec" process, so this has stopped me from narrowing down the
problem further.

Any suggestions on moving forward would be welcome -- for example, would it
be possible to run Emacs undumped, avoiding unexec all together?

    -- Anders


On Fri, Feb 7, 2014 at 10:03 PM, Anders Lindgren <andlind@gmail.com> wrote:

> Hi!
>
> I understand your scepticism about my fingers ;) However, the problem is
> quite apparent, I get bitten by it several times per day. Also, it occurs
> consistently when doing the <tab> <down> sequence in recent versions from
> the trunk. On older versions, however, I don't see this behaviour at all.
>
> Anyway, I tried to script this using AppleScript, asking the "System
> Event" to send keycodes for <tab> and <down>. Unfortunately, Emacs behaves
> perfectly and doesn't loose any key event when scripted.
>
> Just for the record, this is the script I used:
>
> repeat 100 times
>     tell application "System Events" to key code 48      -- TAB
>     tell application "System Events" to key code 125     -- DOWN
> end
>
> I started it from within emacs using M-! osascript xxx.osa RET
>
> One approach to find the faulty revision is to back-patch the fix in
> 111505 into the revisions 110812-111504 to see if one of those revisions
> introduced the problem. (If the problem is in the sequence 110786-110811,
> it will be harder to track down, as they don't build properly). I will try
> to find the time to do this, but I can't give any guarantees...
>
>     -- Anders
>
>
> On Fri, Feb 7, 2014 at 5:06 PM, Dmitry Antipov <dmantipov@yandex.ru>wrote:
>
>> On 02/07/2014 06:17 PM, Anders Lindgren wrote:
>>
>>  Here, a <tab> is missing, which explains the indentation problems.
>>>
>>
>> Hmm...IMHO we shouldn't believe in anyone's fingers in such a case :-).
>>
>> Do you have a tool to fake user input? On X, we have xdotool. I've tried
>> to insert 100 <tab> and 100 <down> with 0.05s delay between each
>> "keypress":
>>
>> xdotool selectwindow ==> (record window ID)
>>
>> seq 99 -1 0 | xargs -n1 sh -c 'xdotool key --window $ID 23 && sleep 0.05
>> && xdotool key --window $ID 116 && sleep 0.05'
>>
>> (23 is X keycode for <tab> and <116> for <down>) and there was 100 <tab>
>> and
>> 100 <down>, respectively...
>>
>> Dmitry
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4368 bytes --]