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 22:00:10 +0200 Message-ID: <87wpx8jigl.fsf@fencepost.gnu.org> References: <87egjh4u1h.fsf@fencepost.gnu.org> <83pp30sd5l.fsf@gnu.org> <87k2t831gf.fsf@fencepost.gnu.org> <871tfgl0e2.fsf@fencepost.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 1438892313 2656 80.91.229.3 (6 Aug 2015 20:18:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 20:18:33 +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 22:18:27 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 1ZNRcR-0007oK-5o for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 22:18:27 +0200 Original-Received: from localhost ([::1]:46523 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNRcQ-0002ZJ-7t for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 16:18:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNRcN-0002Z2-Dd for emacs-devel@gnu.org; Thu, 06 Aug 2015 16:18:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNRcF-0007Et-LF for emacs-devel@gnu.org; Thu, 06 Aug 2015 16:18:23 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:59646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNRcF-0007Ee-Hu for emacs-devel@gnu.org; Thu, 06 Aug 2015 16:18:15 -0400 Original-Received: from localhost ([127.0.0.1]:44448 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZNRcE-0006o5-Jn; Thu, 06 Aug 2015 16:18:15 -0400 Original-Received: by lola (Postfix, from userid 1000) id DB80CE0E47; Thu, 6 Aug 2015 22:00:10 +0200 (CEST) In-Reply-To: <871tfgl0e2.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 06 Aug 2015 20:47:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.10 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:188514 Archived-At: David Kastrup writes: > David Kastrup writes: > >> 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-c= ommand-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. >> >> My test programs used (t . EVENT) after just using EVENT did not do the >> trick either. > > Uh oh. This is bad news for macro recording of list events. > > Defining kbd macro... > Auto-saving...done > is undefined > > and the " is undefined" message comes with an abort of macro > recording. Quite the nuisance. So I'll remove the t thing again and > will see how I fare then. > > Now obviously if my events appear first in unread-command-events, they > cannot already have been added to this-command-keys, but at least list > events apparently must not be added in the (t . EVENT) form or > _something_ will attempt a lookup and fail. > > Since the message appears only _once_, it would appear that the problem > stops occuring the moment macro recording by C-x ( has stopped. > > What a can of worms. Looks like I can (and must) leave off the (cons t ...) for my use case. I haven't seen any bad effects from doing so: events are looked up in keymaps and recorded just fine so far. I don't know what the implications of the t thing are. But other than that, things do look good so far. --=20 David Kastrup