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

[Anders Lindgren]

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