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, 19 Oct 2004 12:46:00 -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> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1098204504 12661 80.91.229.6 (19 Oct 2004 16:48:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 19 Oct 2004 16:48:24 +0000 (UTC) Cc: storm@cua.dk, monnier@iro.umontreal.ca, alexander.pohoyda@gmx.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 19 18:48:13 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 1CJx9g-0006SM-00 for ; Tue, 19 Oct 2004 18:48:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJxH2-0001PV-5s for ged-emacs-devel@m.gmane.org; Tue, 19 Oct 2004 12:55:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CJxFo-0000Xp-CE for emacs-devel@gnu.org; Tue, 19 Oct 2004 12:54:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CJxFn-0000WS-2M for emacs-devel@gnu.org; Tue, 19 Oct 2004 12:54:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJxFm-0000SW-V2 for emacs-devel@gnu.org; Tue, 19 Oct 2004 12:54:31 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CJx7d-0007Fz-GA for emacs-devel@gnu.org; Tue, 19 Oct 2004 12:46:05 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CJx7Y-0000UE-Dy; Tue, 19 Oct 2004 12:46:00 -0400 Original-To: Luc Teirlinck In-reply-to: <200410190158.i9J1wrH25523@raven.dms.auburn.edu> (message from Luc Teirlinck on Mon, 18 Oct 2004 20:58:53 -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:28614 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28614 It would definitely seem to be a lot better to change existing "incorrect" (whatever that means, it seems to be completely subjective) uses than to change `interactive-p'. This way we will not break any currently correct code in the Emacs distribution, third party packages, user Elisp functions and, most importantly, user defined keyboard macros. If most of the uses in Emacs are wrong, and expect interactive-p to have the other meaning, I would expect that the same is true for most uses of interactive-p outside Emacs. After all, those installed in Emacs have received more scrutiny by Emacs developers. The current behavior has been in place for a long time and users have defined (and saved) their keyboard macros to work with that behavior. Sorry, I do not understand. In what way would a keyboard macro be defined "to work with" the current behavior? How would anyone have defined any keyboard macro differently if interactive-p worked the other way. I do not see it. This change would cause certain commands to work differently in keyboard macros, yes, but there is nothing you can do in a keyboard macro to select the other behavior. And there still will be nothing if this change is made. The first step in fixing this is to take inventory. Which uses of interactive-p are correct with the current definition of interactive-p? Which would be correct with the modified definition of interactive-p that would not check for macros? I doubt that many uses are going to be obviously "correct" or "incorrect". We can judge each of them by some predecided criteria of what is right. In as far as the current example is concerned, it would seem _wrong_ to _try_ to show the how-many/count-matches messages in an executing keyboard macro, like it is wrong to _try_ to show _any_ message in a keyboard macro. I don't agree at all. Maybe the above could be considered a bug that should be fixed. But even if this "bug" would be fixed, then if the macro is executed with `C-x e', the "(Type e to repeat macro)" message will still overwrite any message that the macro would try to print. Investigating the reason for this, I found that message3_nolog tests INTERACTIVE, which is 0 when executing a macro. Thus, calls to `message' never display a message while in a keyboard macro. They write into the *Messages* buffer, and that's all they do. So all calls to interactive-p to decide whether to call `message' should be judged based on whether we want to put the message into *Messages*. Anything but a progress message should go into *Messages*. Would someone like to start checking the code that uses interactive-p and judge them? You could put each instance into one of these four categories: * Needs the current definition of interactive-p to be correct. * Needs the changed definition of interactive-p to be correct. * Is correct either way. * You're not sure. If you do that for even 10 of the uses, we should start to get a picture.