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: how-many/count-matches for non-interactive use Date: Sun, 17 Oct 2004 15:53:39 -0500 (CDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200410172053.i9HKrdL01136@raven.dms.auburn.edu> References: <87pt3m5vqk.fsf@oak.pohoyda.family> <87zn2mh5jk.fsf-monnier+emacs@gnu.org> <87is99nznd.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1098046575 19598 80.91.229.6 (17 Oct 2004 20:56:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 17 Oct 2004 20:56:15 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, alexander.pohoyda@gmx.net, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 17 22:56:03 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 1CJI4Q-0003SG-00 for ; Sun, 17 Oct 2004 22:56:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJIBg-0007Uo-Tx for ged-emacs-devel@m.gmane.org; Sun, 17 Oct 2004 17:03:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CJIBU-0007Rn-L0 for emacs-devel@gnu.org; Sun, 17 Oct 2004 17:03:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CJIBT-0007R8-Rf for emacs-devel@gnu.org; Sun, 17 Oct 2004 17:03:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJIBT-0007R0-OC for emacs-devel@gnu.org; Sun, 17 Oct 2004 17:03:19 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CJI3r-0008AA-8C; Sun, 17 Oct 2004 16:55:27 -0400 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 i9HKstiU020074; Sun, 17 Oct 2004 15:54:55 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i9HKrdL01136; Sun, 17 Oct 2004 15:53:39 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: <87is99nznd.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Sun, 17 Oct 2004 11:19:42 -0400) 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:28532 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28532 Stefan Monnier wrote: Sit-for doesn't wait when executed from a macro. As for messages you might be right in some (maybe even in many) cases but I doubt it matters much since unless the message is the last in the macro it will just be overwritten anyway. If the macro is called with M-1000 or M-0, then, if nothing else, all these messages might slow macro execution down. Moreover, if there are at least two different messages printed during execution of the macro, it will also get rid of all previous info in *Messages*. It is not clear to me whether we are currently discussing _changing_ the behavior of `interactive-p', or declaring it obsolete. I believe that changing it now would be very bad. The current behavior is very well documented in both the docstring and the Elisp manual (and even in comments in the source code and such) and has been in effect for a long time. We can theoretically check all occurrences in the Emacs tree (although there are tons of those), but we can not possibly check all packages not included with the Emacs distribution. On the other hand, there also is the problem that `interactive-p' returns t while _defining_ a keyboard macro. It would appear to be deceiving to the user to have different behavior while _defining_ the macro and while executing it. I do not know what declaring a function obsolete _exactly_ means. I believe that what we could do is keep the function around indefinitely in its current form, but discourage its use in new code meant for inclusion in Emacs. If people write their own functions for private use, they might find interactive-p more convenient than the alternative. It also would mean that we would not have to worry about checking all existing calls _right now_. We could then recommend the following in the Elisp manual: (defun foo (&optional interactive-p) (interactive "p") (when interactive-p (message "foo"))) if the message needs to be printed even during keyboard macro-execution and: (defun foo (&optional interactive-p) (interactive "p") (or (not interactive-p) executing-kbd-macro defining-kbd-macro (message "foo"))) if not. Note that the behavior of the latter version of `foo' differs from the current behavior of `interactive-p' by not showing the message during macro definition either. Sincerely, Luc.