From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: new apropos feature in Emacs-22 Date: Sat, 05 Nov 2005 18:43:00 +0200 Message-ID: References: <200511050315.jA53Fjd19148@raven.dms.auburn.edu> <200511051552.jA5FqcX21805@raven.dms.auburn.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1131209053 5474 80.91.229.2 (5 Nov 2005 16:44:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 5 Nov 2005 16:44:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 05 17:44:11 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EYR8Y-0000TT-J8 for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2005 17:43:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EYR8Y-0008KO-1w for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2005 11:43:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EYR8P-0008K8-1C for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:43:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EYR8N-0008Jw-I3 for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:43:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EYR8N-0008Jt-FF for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:43:15 -0500 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EYR8N-0007Tt-Et for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:43:15 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-245-120.inter.net.il [83.130.245.120]) by nitzan.inter.net.il (MOS 3.6.5-GR) with ESMTP id BWH47422 (AUTH halo1); Sat, 5 Nov 2005 18:42:54 +0200 (IST) Original-To: Luc Teirlinck In-reply-to: <200511051552.jA5FqcX21805@raven.dms.auburn.edu> (message from Luc Teirlinck on Sat, 5 Nov 2005 09:52:38 -0600 (CST)) 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:45463 Archived-At: > Date: Sat, 5 Nov 2005 09:52:38 -0600 (CST) > From: Luc Teirlinck > CC: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > This feature (and any ad-hoc rules it implements) was discussed at > length around the time the feature was added. Please be sure to read > those discussions before you suggest to change the decisions made back > then. > > Nothing in that discussion changes the fact that: > > (string-equal (regexp-quote regexp) regexp) > > is just a horrible way to distinguish a regexp from a list of keywords. Please don't get angry with me: I was only trying to say that the seemingly arbitrary rule of "at least two matching keywords" might have some valid reasons which are spelled out in the discussions. I do agree that the doc strings should be updated to reflect the fact that a list of keywords are accepted as well as regexps. > To the person who wants to use a regexp, it is confusing that > `M-x apropos-documentation RET font lock RET" produces tons of > unexpected matches and unexpected highlighting. I think the idea was that a list of words is more natural input at that point than a regexp. People nowadays are used to Google-style queries more than to regexps. FWIW, I rarely myself use regexps in apropos. > To the person who reads the Emacs manual and knows nothing about > regexps, it is even a lot more confusing that things like: > > M-x apropos-documentation RET *scratch* buffer RET > > does not find any matches, even though there are several places matching > both keywords. > > Things like: > > M-x apropos-documentation RET .emacs init RET > > are probably even worse, since _some_ matches are actually displayed, > but not the ones the user may be trying to find. I think these problems were raised and discussed back then, but I might be wrong.