From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: Apropos commands and regexps Date: Thu, 16 May 2002 15:30:30 +0300 Sender: emacs-devel-admin@gnu.org Message-ID: <4098-Thu16May2002153029+0300-eliz@is.elta.co.il> References: <5xg00y41zj.fsf@kfs2.cua.dk> Reply-To: Eli Zaretskii NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1021552381 18097 127.0.0.1 (16 May 2002 12:33:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 16 May 2002 12:33:01 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 178KRJ-0004hm-00 for ; Thu, 16 May 2002 14:33:01 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 178KdJ-00029R-00 for ; Thu, 16 May 2002 14:45:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 178KRV-0003zl-00; Thu, 16 May 2002 08:33:13 -0400 Original-Received: from frigg.inter.net.il ([192.114.186.16]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 178KQu-0003yT-00 for ; Thu, 16 May 2002 08:32:36 -0400 Original-Received: from Zaretsky ([80.230.2.40]) by frigg.inter.net.il (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id BKZ29239; Thu, 16 May 2002 15:32:00 +0300 (IDT) Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9 In-Reply-To: (Kai.Grossjohann@CS.Uni-Dortmund.DE) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3999 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3999 > From: Kai.Grossjohann@CS.Uni-Dortmund.DE > Date: Thu, 16 May 2002 13:04:13 +0200 > > The user enters a query. The system searches items of documentation > and computes a score for each one. Then the items with the highest > score come out first. There is an alternative approach: The user enters a query. The system does the search and presents a menu of possible refinements of the original search spec. The user chooses one of the possibilities, and the process repeats, until the list of possible hits is shorter than some predefined value; when that happens, the list of hits is displayed. The advantage of this method is twofold: - You don't need to invent a good scoring system. - The user never needs to wade through gobs of hits, trying to figure out which one is relevant to his/her query. (If this description doesn't explain the suggestion, I can craft a ficticious example that might help.) I generally find scoring a poor means for me to decide whether the hit is relevant. When I google, for example, I find myself examining the search words shown with surrounding text much more than looking at the scores. But if the number of hits shown is large, my method is not very efficient, and can be even frustrating; thus the suggestion for interactively refining the search before showing the hits. > When searching in info files, some subdivision makes sense I think. > Should each node be considered a retrievable item, or is another > subdivision more sensible? I'd say, as the first approximation, search node names, chapter/section names, index entries, and glossary items.