emacs-devel
[Top][All Lists]
Advanced

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

Re: new apropos feature in Emacs-22


From: Kim F. Storm
Subject: Re: new apropos feature in Emacs-22
Date: Sun, 06 Nov 2005 00:00:19 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Drew Adams" <address@hidden> writes:

> Thanks for the links. I'll keep quiet after this - suffice it to say that I
> don't agree with this new feature, and the "drawbacks" mentioned to using a
> separate command were skimpy.

There was one major reason for this change, and that reason has not changed:

To make it easier for the emacs "novice" to find information with apropos.

The assumption is that most users will be accustomed to use keyword
search, and only the experts will use regular expressions.

So we changed the standard apropos commands to accept keywords, and to keep
things simple, we chose the simple rule of "any two words matches".

Personally, I would have preferred to let apropos use keywords only
(and I haven't used regexps in apropos since this change was made), but
as a compromise, we retained regexp matching if the search pattern looks
like a regexp (and an expert user know how you can easily specify " +"
for a space to force the old semantics).

> That one "drawback" wasn't discussed at all, that I saw. I don't see _why_
> all apropos commands _should_ accept the same type of "search patterns" -
> what is the argument for this? I didn't see any.

IMO, it is the only logical thing to do.  I never thought I'd have to argue
about that...

> Are we perhaps worried about people _expecting_ that all commands that have
> the word "apropos" in their names behave the same way wrt input (unlikely,
> IMO)? Is that the unstated worry? If so:
>
> 1) I think that's being a bit skittish.

It's being "user friendly", and specifically "novice user friendly".

> 2) We could, instead, introduce a command (or a whole series of different
> commands, to respond to the question raised but not answered) that uses
> keywords and does _not_ have the word "apropos" in its name. If that (the
> name) is the only real concern, then let us choose a different name for the
> keyword-search command(s) (hey, how about `keyword-search'?)

_If_ we were to change the current situation, we should make the normal
commands accept keywords only, and make new commands for regexp matches.

> How did the (useful!) feature of keyword search get injected and locked into
> the existing apropos commands? (Virus? ;-))
>
> As I said, we're asking for trouble by trying to mix regexp syntax and
> keyword syntax. The former is confusing enough - imagine how it will be when
> people fall into it by accident! My bet is that neither the regexp syntax
> nor the keyword syntax will be clear cut or work well.

I doubt this is a real problem.  Do you have any evidence (actual user
complaints) to prove your case?

A user falling into this by accident will probably rephrase the query and
try again.  Just like goggling may require a few different sets of keywords
before you find something useful.

And the prompt does say ... (regexp or words), so if the user gets 
a lot of false hits, there is a clue to what went wrong.

>
> Now, I'll shut up, after one last request:
>
> Can we please have available some function(s) that will give the original,
> regexp-syntax-only behavior, so that we may individually get back to
> something reasonable? That is, can we have functions (not necessarily aimed
> at novices) that we can use to build commands that do what the apropos
> family did before? It could be `apropos-internal' (plus equivalents for doc
> etc.) - or something else, if `apropos-internal' has already been infected
> too ;-).

I don't understand why you need this.  If you (as an expert user) want
regexp mathing, specify a regexp -- it's as simple as that!

E.g. instead of "find file" (keyword search), write "find +file" (regexp).

But I agree that the doc strings could be improved.

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





reply via email to

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