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: Tue, 26 Oct 2004 05:05:55 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <87pt3m5vqk.fsf@oak.pohoyda.family> <87zn2mh5jk.fsf-monnier+emacs@gnu.org> <87is99nznd.fsf-monnier+emacs@gnu.org> <200410172053.i9HKrdL01136@raven.dms.auburn.edu> <200410190158.i9J1wrH25523@raven.dms.auburn.edu> <200410200127.i9K1Rpp28384@raven.dms.auburn.edu> <200410210308.i9L38Dm10997@raven.dms.auburn.edu> <200410222222.i9MMMD515903@raven.dms.auburn.edu> <200410240231.i9O2VlZ15381@raven.dms.auburn.edu> <200410250153.i9P1rAA06469@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1098781995 2008 80.91.229.6 (26 Oct 2004 09:13:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 26 Oct 2004 09:13:15 +0000 (UTC) Cc: jpw@gnu.org, klm@zope.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, storm@cua.dk, alexander.pohoyda@gmx.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 26 11:13:08 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 1CMNO8-0001fN-00 for ; Tue, 26 Oct 2004 11:13:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMNVo-00043T-OC for ged-emacs-devel@m.gmane.org; Tue, 26 Oct 2004 05:21:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CMNQ1-0001Fg-J0 for emacs-devel@gnu.org; Tue, 26 Oct 2004 05:15:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CMNPu-0001Dj-2i for emacs-devel@gnu.org; Tue, 26 Oct 2004 05:14:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMNPt-0001Da-Ox for emacs-devel@gnu.org; Tue, 26 Oct 2004 05:14:57 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CMNHe-0003wO-Bf for emacs-devel@gnu.org; Tue, 26 Oct 2004 05:06:26 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CMNH9-00036O-F7; Tue, 26 Oct 2004 05:05:56 -0400 Original-To: Luc Teirlinck In-reply-to: <200410250153.i9P1rAA06469@raven.dms.auburn.edu> (message from Luc Teirlinck on Sun, 24 Oct 2004 20:53:10 -0500 (CDT)) 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:28966 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28966 I know looked at the three remaining calls in simple.el myself. The call in `kill-ring-save' _seems_ to me to be an example of correct non-message use. I agree, in this case. This code gives the user visual feedback, which is what message does. There are tons of uses in help.el, help-fns, faces.el, apropos.el, which are all of exactly the same "help-xref" type. I did not check these. However, I somehow get the impression that whoever wrote the code knew what they were doing. I think those are all erroneous. The behavior controlled in this case is clearing a stack. Whether to clear the stack should be the same regardless of whether a keyboard macro is executing. Can someone look at how to fix these? That leaves: I started checking these, and I found: man.el: Man-cleanup-manpage I think the reason for checking interactive-p here is just in case someone wants to do M-x Man-cleanup-manpage. I am not sure that feature is worth having, but in any case the code is not correct. menubar.el: menu-bar-make-toggle That was a bug. It was using interactive-p to control whether to call customize-mark-as-set. The toggle command would have done the wrong thing in a keyboard macro. pcomplete.el: pcomplete That is a bug too. The code does something substantive, not just visual feedback for the user. woman.el: woman That is a bug too. The code it controls does find-file; it is not just visual feedback. So far, four errors out of four. I fixed these. Could other people check the rest? The rule is simple: if it conditionalizes anything more than visual feedback for the user, it is wrong to use interactive-p. Therefore, you don't have to really master the code to fix these problems. Here is what is left on that list: comint.el: comint-strip-ctrl-m strokes.el: several. Of those, strokes-prompt-user-save-strokes is another one that seems suspicious. I am completely unfamiliar with strokes.el. But these seem to be mouse related functions. I do not know whether calling these from keyboard macros makes any sense to begin with. newcomment.el: comment-indent-new-line printing.el: several dired-x.el: dired-omit-expunge, dired-x-bind-find-file bookmark.el: bookmark-maybe-historicize-string, bookmark-bmenu-list ffap.el: several. completion.el: add-completion, add-permanent-completion