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
>
>