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: (no subject) Date: Fri, 22 Oct 2004 17:14:54 -0500 (CDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200410222214.i9MMEsc15892@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1098483419 18853 80.91.229.6 (22 Oct 2004 22:16:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 22 Oct 2004 22:16:59 +0000 (UTC) Cc: Ken Manheimer , John Paul Wallington Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 23 00:16: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 1CL7iI-0002MW-00 for ; Sat, 23 Oct 2004 00:16:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CL7po-0006Qh-9e for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2004 18:24:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CL7pZ-0006QZ-Pi for emacs-devel@gnu.org; Fri, 22 Oct 2004 18:24:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CL7pY-0006Pr-Nm for emacs-devel@gnu.org; Fri, 22 Oct 2004 18:24:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CL7pY-0006Pi-Hx for emacs-devel@gnu.org; Fri, 22 Oct 2004 18:24:16 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CL7hw-0004IS-Dl; Fri, 22 Oct 2004 18:16:24 -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 i9MMGNiU022145; Fri, 22 Oct 2004 17:16:23 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i9MMEsc15892; Fri, 22 Oct 2004 17:14:54 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org 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:28748 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28748 I took a look at all calls to `interactive-p' in the Emacs Elisp code. For many (actually most) it is impossible to check whether the call is "correct" without studying tons of code, which I did not do and am not going to do. For most others, the current behavior prevents nuisance messaging, as intended. _Maybe_ the following are exceptions to that (they should be checked further). Most of these seem to abuse `interactive-p' to read their arguments outside the interactive declaration. (Something that should be avoided anyway, regardless of the negative effect on keyboard macros.) 1. Info-goto-emacs-key-command-node I can not check this one right now, because `Info-goto-emacs-command-node' seems broken. I do not even know whether this is worth worrying about. It would seem to make no sense to define a macro that always checks the documentation for the _same_ command. Better use bookmarks in that case. 2. Three functions in `indent.el'. I could check these out further. If they give any problems, they are trivial to fix. Apart from that, two files _seem_ to have problems: ibuf-ext.el, in particular the function `ibuffer-jump-to-buffer' and allout.el, in particular `allout-init', `allout-backward-current-level' and maybe others. I CC the maintainers of those files. They can better determine than I do whether the calls to interactive-p in those files are appropriate and in particular, appropriate for keyboard macros. Like I said I do not know whether the above list of (potential) problems is exhaustive. It probably is not. Checking every single call to `interactive-p' in detail is hopeless. But what we know is that the current behavior of `interactive-p', which has been in place for a long time, has not exactly led to a flood of complaints from keyboard macro users. Keyboard macro users appear to be happy with the current situation. What we do not know is whether changing the behavior will lead to a flood a bug reports and complaints about macro execution speed getting ruined. Sincerely, Luc.