From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Another bug with the macro counter Date: Sun, 31 Oct 2004 15:01:05 -0600 (CST) Message-ID: <200410312101.i9VL15p06356@raven.dms.auburn.edu> References: <200410210107.i9L176B10842@raven.dms.auburn.edu> <200410300238.i9U2cOD02290@raven.dms.auburn.edu> <200410300327.i9U3RWW02355@raven.dms.auburn.edu> <200410301451.i9UEpNG02900@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1099256535 27225 80.91.229.6 (31 Oct 2004 21:02:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 31 Oct 2004 21:02:15 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 31 22:02:05 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1COMpx-000321-00 for ; Sun, 31 Oct 2004 22:02:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1COMxu-0002iV-W0 for ged-emacs-devel@m.gmane.org; Sun, 31 Oct 2004 16:10:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1COMxl-0002he-Dh for emacs-devel@gnu.org; Sun, 31 Oct 2004 16:10:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1COMxk-0002hC-9L for emacs-devel@gnu.org; Sun, 31 Oct 2004 16:10:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1COMxj-0002h3-VP for emacs-devel@gnu.org; Sun, 31 Oct 2004 16:10:08 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1COMpJ-0005HA-ME for emacs-devel@gnu.org; Sun, 31 Oct 2004 16:01:25 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i9VL1IFu004561; Sun, 31 Oct 2004 15:01:18 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i9VL15p06356; Sun, 31 Oct 2004 15:01:05 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: storm@cua.dk In-reply-to: (storm@cua.dk) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29243 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29243 Your alternate patch seems OK, but I would make three changes to it. First one: + (defun kmacro-keyboard-quit () + (or kmacro-appending-p + (kmacro-ring-empty-p) + (kmacro-pop-ring)) + (setq kmacro-appending-p nil)) As you may already have pointed out yourself, you actually need: + (defun kmacro-keyboard-quit () + (or (not defining-kbd-macro) kmacro-appending-p + (kmacro-ring-empty-p) + (kmacro-pop-ring)) + (setq kmacro-appending-p nil)) The second one is that I would rename kmacro-appending-p to kmacro-appending-flag. >>From `(elisp)Tips for Defining': `...-flag' The value is significant only as to whether it is `nil' or not. The `-p' convention is for functions. The third one is that I would keep the docstring I gave for kmacro-appending-flag: "Non-nil when appending to a keyboard macro definition. The value is nil when defining a new keyboard macro. In other situations, the value is undefined." The `(setq kmacro-appending-p nil)' is not sufficient to guarantee that kmacro-appending-p will be nil outside a macro definition. There are two reasons to quit inside a keyboard macro. The first, in my usage by far the most common, is that you start defining a macro and then mess it up. You do C-g while Emacs is waiting for keyboard input to get rid of the erroneous macro. Currently that duplicates the last correct keyboard macro in a confusing way. This is the situation we are trying to correct. The second is that a function called during the keyboard macro definition takes a huge amount of time and the user quits to regain control. In this situation, `keyboard-quit' is not called and the quit is handled by QUIT. Now the C-g terminates the macro definition without becoming part of it, just like C-x ). The new macro is likely to be useless. Unlike in the first case, the user can not but notice what happened and hence can remove the macro with C-x C-k C-d. This situation remains unchanged after either your or my patch. If this situation happens while appending to a keyboard macro, then kmacro-appending-p will remain t, even though no macro is being defined. I could give a concrete example if desired. Sincerely, Luc.