From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Severe lossage from unread-command-events Date: Thu, 06 Aug 2015 17:01:52 +0200 Message-ID: <87k2t831gf.fsf@fencepost.gnu.org> References: <87egjh4u1h.fsf@fencepost.gnu.org> <83pp30sd5l.fsf@gnu.org> 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 1438873710 18809 80.91.229.3 (6 Aug 2015 15:08:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 15:08:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 06 17:08:14 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 1ZNMmE-0002Be-9m for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 17:08:14 +0200 Original-Received: from localhost ([::1]:45500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNMmD-0006ah-Fo for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 11:08:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNMm8-0006aD-AL for emacs-devel@gnu.org; Thu, 06 Aug 2015 11:08:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNMm4-0007uh-Vy for emacs-devel@gnu.org; Thu, 06 Aug 2015 11:08:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNMm4-0007ub-Sx for emacs-devel@gnu.org; Thu, 06 Aug 2015 11:08:04 -0400 Original-Received: from localhost ([127.0.0.1]:39545 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZNMm4-00071a-76; Thu, 06 Aug 2015 11:08:04 -0400 Original-Received: by lola (Postfix, from userid 1000) id 4910DE0E47; Thu, 6 Aug 2015 17:01:52 +0200 (CEST) In-Reply-To: <83pp30sd5l.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 06 Aug 2015 17:29:58 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:188504 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Date: Wed, 05 Aug 2015 17:46:50 +0200 >>=20 >> run the included test file using >>=20 >> emacs -Q -l timer-test.el >>=20 >> and then open the generated dribble file /tmp/mydrib. On my computer, >> it looks something like >>=20 >> 000000000000000000111111111111111111122222222222222222222333333333333333= 344444444444444444455555555555555555666666666666666666777777777777777777888= 8888888888888899999999999999999 >>=20 >> which means that of 4000 events having an effect in the scratch buffer, >> about 5% (a non-deterministic amount) are actually recorded in the >> dribble file. In particular, it looks like only the first of several >> events placed into unread-command-events at one point of time will ever >> see the dribble file. While I am only moderately interested in actually >> generating a useful dribble file, the same holds for macro recording. >> And I have an actual application which is severely impacted here. >>=20 >> Note that _all_ of the events (usually) are actually processed as input >> in the *scratch* buffer. It is only the recording of them which falls >> really, really flat on its face. > > My reading of the code in read_char is that when we consume events > from unread-command-events, we don't always record the events we find > there. 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: 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-comm= and-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 lis= t. My test programs used (t . EVENT) after just using EVENT did not do the trick either. However, I don't think most of the other uses of unread-command-events I have seen bother doing so. It might or might not be a red herring. > Does the following na=C3=AFve attempt at fixing this give good results? = If > not, can you tell why not, or show a test case where it misbehaves? I'll be giving it a try. 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. Or whether the code is in need of reorganization before one can hope to get it right anyway. Thanks, --=20 David Kastrup