From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: how-many/count-matches for non-interactive use Date: Thu, 14 Oct 2004 20:26:24 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <87pt3m5vqk.fsf@oak.pohoyda.family> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1097800013 19272 80.91.229.6 (15 Oct 2004 00:26:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Oct 2004 00:26:53 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 15 02:26:46 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 1CIFvi-0003u1-00 for ; Fri, 15 Oct 2004 02:26:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CIG2p-0001DX-BK for ged-emacs-devel@m.gmane.org; Thu, 14 Oct 2004 20:34:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CIG2c-0001CX-Og for emacs-devel@gnu.org; Thu, 14 Oct 2004 20:33:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CIG2b-0001Bk-Ck for emacs-devel@gnu.org; Thu, 14 Oct 2004 20:33:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CIG2b-0001Bf-3q for emacs-devel@gnu.org; Thu, 14 Oct 2004 20:33:53 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CIFvN-0005dd-Fy for emacs-devel@gnu.org; Thu, 14 Oct 2004 20:26:25 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CIFvM-0006Nf-U4; Thu, 14 Oct 2004 20:26:25 -0400 Original-To: Alexander Pohoyda In-reply-to: <87pt3m5vqk.fsf@oak.pohoyda.family> (message from Alexander Pohoyda on 13 Oct 2004 20:16:51 +0200) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28400 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28400 How about this patch? Index: replace.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v retrieving revision 1.171 diff -u -r1.171 replace.el --- replace.el 30 May 2004 21:50:35 -0000 1.171 +++ replace.el 13 Oct 2004 18:14:35 -0000 @@ -490,7 +490,9 @@ (if (= opoint (point)) (forward-char 1) (setq count (1+ count)))) - (message "%d occurrences" count)))) + (if (interactive-p) + (message "%d occurrences" count) + count)))) interactive-p is the wrong function to call here, because it is nil when the command is called froma keyboard macro. The right thing to do here is to take an argument saying whether to print the message, and use "p" in the interactive spec to set that argument non-nil in an interactive call. It seems that interactive-p as currently defined is very rarely useful -- perhaps never. Perhaps we should change interactive-p to ignore whether the command is running from a macro and do what most people seem to expect. It would be useful for someone to find all calls to interactive-p and see if any of them really want interactive-p to do what it is currently defined to do. I just grepped for it, and looked at two calls in bookmark.el; I think the second one should be changed, but I can't tell about the first with a quick glance. I looked at the one call in emerge.el and I think it should be changed. I looked at the call in env.el and I think it should be changed. I looked at the call in faces.el, in describe-face, where it is used as an argument to help-setup-xref. It tells whether to clear the stack of help xrefs followed. I tend to think this should be changed, because the command should behave the same in a macro as it would when not called from a macro. So are there any calls to interactive-p that really want it to return nil when running in a keyboard macro?