From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: new apropos feature in Emacs-22 Date: Mon, 7 Nov 2005 09:54:00 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1131386308 1694 80.91.229.2 (7 Nov 2005 17:58:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Nov 2005 17:58:28 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 07 18:58:26 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EZBCX-0003Cg-5a for ged-emacs-devel@m.gmane.org; Mon, 07 Nov 2005 18:54:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EZBCW-0004fX-3y for ged-emacs-devel@m.gmane.org; Mon, 07 Nov 2005 12:54:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EZBC2-0004aq-08 for emacs-devel@gnu.org; Mon, 07 Nov 2005 12:54:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EZBC0-0004ZX-Sc for emacs-devel@gnu.org; Mon, 07 Nov 2005 12:54:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EZBC0-0004ZE-LX for emacs-devel@gnu.org; Mon, 07 Nov 2005 12:54:04 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EZBC0-00010T-Ob for emacs-devel@gnu.org; Mon, 07 Nov 2005 12:54:04 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA7I4inh008970 for ; Mon, 7 Nov 2005 12:04:44 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA7Hs1UO009037 for ; Mon, 7 Nov 2005 10:54:01 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jA7Hs1ma009029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Nov 2005 10:54:01 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:45555 Archived-At: This feature changes the syntax and meaning of the input to apropos functions. We've discussed the effects on the users of apropos commands. There is also a (similar) effect on the programmatic use to consider. While it is true that there are internal apropos functions that programs could use instead of using the end-user commands: 1. There is no guarantee that programs do not use the end-user commands. 2. In some cases, there is no internal function that directly does what's needed. For example, there is no internal equivalent of `apropos-variable' (IIUC). 3. There is (still) no documentation for most of the internal commands (apropos-documentation-check-doc-file, apropos-documentation-check-elc-file, apropos-documentation-internal, apropos-symbols-internal, apropos-value-internal). This can suggest to programmers that the internal functions are not intended to be used externally. Most of the discussion has centered on _how_ to obtain the syntax and behavior of both the old (regexp) and the new (keywords) apropos at the same time, in the same command - not on whether or not that is desirable. The latest suggestion for combining the old and new in the same command was to use `M-r' to toggle between old and new (in addition to `C-u' to toggle `do-all') - and to add a new user option for selecting the default behavior. This, like the other suggestions, is workable, but it doesn't help existing programmatic use of the commands. In order to not break existing code: 1. An extra (e.g. optional) parameter would need to be provided to the commands. 2. Its default value (nil) would need to reflect the old behavior. #2 conflicts with the desire to make the default syntax and behavior be keyword search, in order to be more "novice user-friendly". We could treat the interactive and programmatic values oppositely wrt to this parameter, of course, but that would be downright mischievous. I argued that the old and new syntaxes and behaviors should be implemented in different commands. That would give all users what they want, without the complexities of modes and mixed syntaxes. It would also not break any existing code. (I also said that I didn't care which commands got the "apropos" name, but I've changed my mind on that, after thinking about existing programs that might expect the old behavior from the "apropos" names. That is, I don't really care about the names, but existing programs might.) I've still seen _no argument_ (i.e. no rationale) voiced against using separate commands. One could argue "Occam's razor: don't multiply things needlessly", but that applies equally to all approaches discussed so far - whether we multiply the number of commands or the number of use modes (e.g. `M-r' toggle) for the existing commands. So, I repeat the question: _Why not_ leave the apropos commands as they were, and create new, more "novice user-friendly", keyword-search commands? The question deserves some reply, at least. It should have been addressed before launching a discussion of _how_ to change the existing commands.