emacs-devel
[Top][All Lists]
Advanced

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

Re: Apropos commands and regexps


From: Richard Stallman
Subject: Re: Apropos commands and regexps
Date: Fri, 17 May 2002 13:28:32 -0600 (MDT)

    For the query language, I see these possibilities:

    * List of words.

      Here, items containing all words will come out first, followed by
      items with all but one word, and so on.  The presence or absence of
      a very common word has less effect on the score than the presence
      or absence of an unusual word.

I think that is the best way to handle the argument.  But the search
for these words should allow them to be substrings of words.  It should
not require an exact match against an entire word in the command name.

    * If the word occurs in a command/function/variable name, then the
      score should be higher than a match in the docstring (or other
      explanatory text) only.

I am not sure it is worth distinguishing.  If the user says to look
at the doc string, treat it as equally important.

    * If the word does not occur at all, but a synonym of the word does,
      the item should match (perhaps with a lowered score).

The synonym may as well have the same score.  We don't need
a feature to make it different.

    * Instead of just synonyms, also consider more general terms,
      more specific terms, related terms.

That would match too much, so I recommend against writing it.

    * If the word does not occur, but a derived form does, then the item
      should match (perhaps with a lowered score).  So "mouse" should
      find "mice" and so on.  The Porter stemming algorithm appears to be
      a useful thing here.

These plurals can be defined as synonyms, so this is not needed
as a separate feature.

    * I guess that "igrep" should be considered a "derived form" of "grep"
      in the context of the Emacs documentation.  Do we do this with an
      explicit synonym list?  Or perhaps with a metric of similarity
      between terms which is based on editing distance or suchlike?

Substring matching will handle this with no extra features.



reply via email to

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