From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Severe lossage from unread-command-events Date: Thu, 06 Aug 2015 18:25:35 +0300 Message-ID: <83io8ssakw.fsf@gnu.org> References: <87egjh4u1h.fsf@fencepost.gnu.org> <83pp30sd5l.fsf@gnu.org> <87k2t831gf.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1438874761 4624 80.91.229.3 (6 Aug 2015 15:26:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 15:26:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 06 17:25:54 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZNN3J-0007Eh-5y for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 17:25:53 +0200 Original-Received: from localhost ([::1]:45550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNN3H-0003De-Tr for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 11:25:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNN3E-0003DP-PS for emacs-devel@gnu.org; Thu, 06 Aug 2015 11:25:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNN3D-0007nK-OQ for emacs-devel@gnu.org; Thu, 06 Aug 2015 11:25:48 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:33162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNN38-0007jx-Q0; Thu, 06 Aug 2015 11:25:42 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NSO00F002MN3B00@a-mtaout20.012.net.il>; Thu, 06 Aug 2015 18:25:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NSO00E8E2USUP60@a-mtaout20.012.net.il>; Thu, 06 Aug 2015 18:25:41 +0300 (IDT) In-reply-to: <87k2t831gf.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188505 Archived-At: > From: David Kastrup > Cc: emacs-devel@gnu.org > Date: Thu, 06 Aug 2015 17:01:52 +0200 >=20 > > My reading of the code in read_char is that when we consume event= s > > from unread-command-events, we don't always record the events we = find > > there. >=20 > Well, according to how I read the variable description of > unread-command-events, some are bounced back there from input which= has > already been recorded. The description reads: >=20 > Documentation: > List of events to be read as the command input. > These events are processed first, before actual keyboard input. > Events read from this list are not normally added to =E2=80= =98this-command-keys=E2=80=99, > as they will already have been added once as they were read for= the > first time. > An element of the form (t . EVENT) forces EVENT to be added to = that list. This talks about a different kind of "recording", the one that stores keyboard input in this-command-keys. My changes don't touch that (at least I hope they don't ;-) > The code in keyboard.c is complex to a degree where I do not trust > myself to venture a guess regarding the nature of the right fix. I agree. I originally waited for one of the handful of people who know their ways inside that function to speak up, but they never did. To see what's going on, I instrumented the code with special printouts, and clearly saw that we only record the events that are taken from unread-command-events in one of two possible places in the code, where we have fragments such as this one: if (CONSP (Vunread_command_events)) { [...] c =3D XCAR (Vunread_command_events); Vunread_command_events =3D XCDR (Vunread_command_events); One such fragment is at the beginning of read_char, around line 2430 of keyboard.c -- the events taken there are not recorded, because we jump over the code that records them. The second such fragment is around line 2815 of keyboard.c -- the events we take there _are_ recorded by the call to record_char on line 2992. Now, since your timer fires at very high frequency, many events are pushed before we see them on line 2815. We extract only the first event there, and it is recorded. The rest are handled by the code at line 2430, and are not recorded, AFAICS. My changes cause them to be recorded, or at least your simple test seems to produce reasonable results. > Or whether the code is in need of reorganization before one can hop= e > to get it right anyway. It's next to impossible to reorganize code one doesn't fully understand, and do a good job.