emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Why do apropos commands match only pairs of words in a word-list pat


From: Drew Adams
Subject: RE: Why do apropos commands match only pairs of words in a word-list pattern?
Date: Mon, 11 May 2015 10:01:36 -0700 (PDT)

> the design was discussed in this long thread:
>   http://lists.gnu.org/archive/html/emacs-devel/2002-05/msg00397.html
> You will see that the heuristic in question did get some attention.

Thanks for the reference.  I'll pull out what I see as a summary, with
some comments from me.

The arguments given there in favor of the current, 2-or-more, design and
against a straightforward AND design boiled down to these 3, all from Kim:

1. Emacs has few return hits anyway.

 For WEB search engines, I think AND does make sense -- since there
 are SOOOO many pages to match.  But for a limited universe like
 emacs -- which doesn't always use the most obvious terms --
 using AND doesn't make a lot of sense to me.

2. It's good enough.

 I think it is adequate in practice.

3. It is more helpful when you don't know exactly what you're looking for.

 [it] has a more "novice" appeal: if don't know what a specific
 function is called, it will be easier to enter a few more alternatives,
 and see what turns up. -- it specifying more words returns more
 alternatives.

 matching at least two keywords will find all the entries found by
 searching for all combinations - and it may find some entries the
 user didn't think about

My response to these arguments:

1. It's not clear to me that the "limited universe" of Emacs is so
   limited that it is helpful to include the noise of false positives.

2. And that "adequate in practice" argument echoes the more-or-less
   apologetic comment in the code that suggests that the design is
   not ideal (not really what we want) but is probably OK in general.

3. And I think it is a mistake to try to be "smart", guessing that
   what's best for a novice by using "dumb" matching.  If you want
   to try to be smart then you need to do something more/other than
   just return all matches of any two of the words.

More importantly, as I said, I think this should be a user choice,
not just a design-time choice.  Even Kim suggested user choice:

 We could put a "button bar" at the top of the apropos output with
 the following buttons:

   [Match all words]  [anchored match]  [search documentation]

(No such user choice was ever implemented, AFAIK.)

Back to my summary of the thread -

A certain Eli Z came out clearly in favor of AND, and against OR'd
pairwise (AND) matches:

 Perhaps that's because they want to show off the number of hits
 they return.  I was always annoyed by ORing, and many times catch
 myself forgetting to type the magic that makes it do an AND.
 Because I always want the AND method.

and

 > I don't like the "and" approach -- at least not as the default.

 I'm afraid anything else will bring too many hits.  A docs search
 tool that returns gobs of information is not very useful, in my
 experience.

and

 I'm afraid this rule will bring many false hits, and I think we
 should beware of that as the plague.

Kim then backed off a bit from pairwise matching:

 if matching only two words gives too many matches for documentation,
 require three (or four) matching words.

To which Mr Z said:

 a rule based on the number of matched keywords is not good enough,
 since sometimes even one word is enough to yield a very  accurate
 result.

Miles said (and Mr Z agreed):

 I think it's clear that we need a bit of experience with this
 stuff, so we can see how well the various alternatives actually
 work in practice, rather than sitting around pontificating...

Well, we don't seem to have experimented with different approaches,
but rather have just gone with OR'd AND'd pair matches. In the end,
RMS decided that pairwise matching "seems more useful", Kim
implemented it, and that was that.

Note that Kai G mentioned what Nicolas R suggested recently: It's OK
to return tons of hits, including noise, if you sort by relevance.
And RMS said "that is the best way to handle the argument".

But as I said before, a major problem with that approach is that it
interferes with other sort possibilities.  If you have many hits, most
of which are noise, the *only* order in which the noise can reasonably
be ignored is relevance (e.g. more AND matches first, fewer later).
You cannot reorder those alphabetically, or by putting all function
names first, then variable names, or any other meaningful order.
Doing that would push all the noise throughout the list of hits.

IOW, a high-noise (high recall, low precision) return set requires
an ordering that keeps the noise farther from immediate view.  Users
deserve to be able to use different sort orders, and the approach
of noise-might-help-sometimes-&-costs-nothing-if-far-from-view
interferes with sorting.

Finally, Eli mentioned also the possibility that is used in Icicles
and probably some other completion UIs: let the user progressively
refine the set of returned hits.

 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 user never needs to wade through gobs of hits, trying to
 figure out which one is relevant to his/her query.

Whether the hits returned at each refinement stage are displayed
or not is not the question (IMO).  In Icicles, a user can choose
whether to see the hits at each stage.  But it is generally useful,
IMO, to show them, even when there are many.  That doesn't imply
that a user must "wade through" them, but s?he can get an idea 
of what's there - and that helps guide upcoming refinement patterns.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]