From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) Date: Sat, 8 Feb 2014 21:04:13 +0100 Message-ID: References: <52F50481.8080509@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd6c03e4f428a04f1ea9c2d X-Trace: ger.gmane.org 1391889913 28809 80.91.229.3 (8 Feb 2014 20:05:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Feb 2014 20:05:13 +0000 (UTC) Cc: larsi@gnus.org, Dmitry Antipov To: 16505@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 08 21:05:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WCE9O-0000xU-26 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Feb 2014 21:05:18 +0100 Original-Received: from localhost ([::1]:47841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCE9N-0006Ir-Dt for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Feb 2014 15:05:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCE9E-00069k-Qb for bug-gnu-emacs@gnu.org; Sat, 08 Feb 2014 15:05:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCE98-0004fg-Rv for bug-gnu-emacs@gnu.org; Sat, 08 Feb 2014 15:05:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCE98-0004fK-PG for bug-gnu-emacs@gnu.org; Sat, 08 Feb 2014 15:05:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WCE97-0000ST-Q4 for bug-gnu-emacs@gnu.org; Sat, 08 Feb 2014 15:05:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Feb 2014 20:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16505 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16505-submit@debbugs.gnu.org id=B16505.13918898581690 (code B ref 16505); Sat, 08 Feb 2014 20:05:01 +0000 Original-Received: (at 16505) by debbugs.gnu.org; 8 Feb 2014 20:04:18 +0000 Original-Received: from localhost ([127.0.0.1]:58179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCE8P-0000RB-5B for submit@debbugs.gnu.org; Sat, 08 Feb 2014 15:04:17 -0500 Original-Received: from mail-ob0-f181.google.com ([209.85.214.181]:52690) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCE8M-0000R0-Na for 16505@debbugs.gnu.org; Sat, 08 Feb 2014 15:04:15 -0500 Original-Received: by mail-ob0-f181.google.com with SMTP id va2so5643248obc.12 for <16505@debbugs.gnu.org>; Sat, 08 Feb 2014 12:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A4GiUJtexP2o6Qt+tZHnKS9rzs2femD6CAAVSIeNcHU=; b=HeuVjCAlKn+UirzQ4sk5Vfk+xPyPCt/RruGrgVZy5Aqg9N5tg1kP6F8Vd/KMTnWCVu gYVesFDbXBuL1ym9j/jJQMGhLT9hSORuSLYP64detp20Bz0dS80sp9g+ZAMlGhS+Ea/j yiiWY/Aa+oftRMsa7l1tVXWmNxClP2inkD1ffkA9ogMQqR0hbjWKDADyD9YmAQ56oJpy Jus3agG5XR5rzz4HPvzUAQXekb/Hz4HyB4bPVll1c5l1uqskyyFm3RkdAWuS7wyk4FVC W526KCXzVTjZ4F1tJPTOrpVXyXFqhccmG55RcgA3cHurjvug11LfJfhuz57lE4bJGJY8 wT1g== X-Received: by 10.60.174.167 with SMTP id bt7mr2575440oec.54.1391889853921; Sat, 08 Feb 2014 12:04:13 -0800 (PST) Original-Received: by 10.182.114.199 with HTTP; Sat, 8 Feb 2014 12:04:13 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:84980 Archived-At: --047d7bd6c03e4f428a04f1ea9c2d Content-Type: text/plain; charset=ISO-8859-1 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 >> >> > --047d7bd6c03e4f428a04f1ea9c2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!

I have narrowed down the possible b= zr revision candidates.

By back-applying 111505 in= to 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 t= he "key dropped" problem. In other words, the problem must have b= een introduced somewhere in the range 110796..110811.

Unfortunately, I get a build error below for these revi= sions. 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 -- f= or example, would it be possible to run Emacs undumped, avoiding unexec all= together?

=A0 =A0 -- Anders


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

I un= derstand your scepticism about my fingers ;) However, the problem is quite = apparent, I get bitten by it several times per day. Also, it occurs consist= ently when doing the <tab> <down> sequence in recent versions f= rom the trunk. On older versions, however, I don't see this behaviour a= t all.

Anyway, I tried to script this using AppleScript, askin= g the "System Event" to send keycodes for <tab> and <dow= n>. 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
=A0 =A0 tell application = "System Events" to key code 48 =A0 =A0 =A0-- TAB
=A0 = =A0 tell application "System Events" to key code 125 =A0 =A0 -- D= OWN
end

I started it from within emacs usin= g M-! osascript xxx.osa RET

One approach to find t= he faulty revision is to back-patch the fix in 111505 into the revisions 11= 0812-111504 to see if one of those revisions introduced the problem. (If th= e 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...

=A0 =A0 -- Anders


On Fri, Feb 7, 2014 at 5:06 PM, Dmitry Antipov <dmant= ipov@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 trie= d
to insert 100 <tab> and 100 <down> with 0.05s delay between eac= h "keypress":

xdotool selectwindow =3D=3D> (record window ID)

seq 99 -1 0 | xargs -n1 sh -c 'xdotool key --window $ID 23 && s= leep 0.05 && xdotool key --window $ID 116 && sleep 0.05'= ;

(23 is X keycode for <tab> and <116> for <down>) and ther= e was 100 <tab> and
100 <down>, respectively...

Dmitry



--047d7bd6c03e4f428a04f1ea9c2d--