emacs-devel
[Top][All Lists]
Advanced

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

Re: Apropos commands and regexps


From: Kim F. Storm
Subject: Re: Apropos commands and regexps
Date: 15 May 2002 23:55:35 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50

Richard Stallman <address@hidden> writes:

>     I think giving the apropos commands a keyword based interface is a
>     good way to accomplish (a), and having an specific apropos-keywords
>     command breaks (b).
> 
> Are you suggesting all apropos commands should work by keywords
> instead of by regexps?

Instead of: no
In addition to: yes

> 
>     Your "all permutations" seems useful -- but I wonder whether it is
>     overkill...
> 
>     So my idea of just searching for any entry 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...
> 
> What exactly is the difference between these two alternatives?
> That isn't clear to me.

If a user enters keywords "find window mini", the first approach will
only find the entries containing all of find, window, and mini, while
the second approach will find the entries which contains two or more
of the keywords.

Using the second approach 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.


> 
>     The obvious problem restricting this to complete words is how to make
>     e.g. "list process" match "list-processes".
> 
> That is a good point.  We want the specified keywords to match
> subsets of words in the command name.

And if the user enters `grep', it should also match `igrep' (if that
command exists).

> 
>     I wonder if the `apropos keyword' command being discussed could maintain
>     a list of common `equivalents', and try substituting some if the
>     original apropos doesn't return anything useful (or maybe even if
>     returns only a few matches).
> 
> That is a natural extension.

Yes, I like that proposal.

> 
> Looking for an equivalent in this list should work by substring match
> too.  And if an equivalent is found, searching for it in command names
> or elsewhere should also use substring match.

I agree.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk




reply via email to

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