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 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 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 and . 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 wrote: > >> On 02/07/2014 06:17 PM, Anders Lindgren wrote: >> >> Here, a 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 and 100 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 and <116> for ) and there was 100 >> and >> 100 , respectively... >> >> Dmitry >> >> >