From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: how-many/count-matches for non-interactive use Date: Mon, 18 Oct 2004 10:39:18 +0200 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098088907 17922 80.91.229.6 (18 Oct 2004 08:41:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 18 Oct 2004 08:41:47 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, alexander.pohoyda@gmx.net, rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 18 10:41:37 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 1CJT5F-0005nv-00 for ; Mon, 18 Oct 2004 10:41:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJTCW-0002wN-Di for ged-emacs-devel@m.gmane.org; Mon, 18 Oct 2004 04:49:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CJTAR-0002F6-W7 for emacs-devel@gnu.org; Mon, 18 Oct 2004 04:47:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CJTAM-0002Da-Uw for emacs-devel@gnu.org; Mon, 18 Oct 2004 04:46:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJTAM-0002DQ-Ij for emacs-devel@gnu.org; Mon, 18 Oct 2004 04:46:54 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1CJT30-0008LR-AF for emacs-devel@gnu.org; Mon, 18 Oct 2004 04:39:18 -0400 Original-Received: (qmail 50259 invoked from network); 18 Oct 2004 08:39:17 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 18 Oct 2004 08:39:17 -0000 Original-To: Luc Teirlinck In-Reply-To: <200410172053.i9HKrdL01136@raven.dms.auburn.edu> (Luc Teirlinck's message of "Sun, 17 Oct 2004 15:53:39 -0500 (CDT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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:28552 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28552 Luc Teirlinck writes: > 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*. Another good point in favour of the current functionality! > > 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 see this as a feature -- not a problem. I think it would be far more confusing if a command behaves differently when defining a macro. > 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. Or enhance it: (interactive-p) => current behaviour (interactive-p t) => interactive or executing macro (interactive-p 1) => interactive or executing macro ONCE > 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: This would be good. > > (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. > > > > -- Kim F. Storm http://www.cua.dk