unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: new apropos feature in Emacs-22
Date: Sun, 06 Nov 2005 00:00:19 +0100	[thread overview]
Message-ID: <m3irv6em4c.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICCEGOCOAA.drew.adams@oracle.com> (Drew Adams's message of "Sat, 5 Nov 2005 12:38:37 -0800")

"Drew Adams" <drew.adams@oracle.com> 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 <storm@cua.dk> http://www.cua.dk

  parent reply	other threads:[~2005-11-05 23:00 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-05  3:15 new apropos feature in Emacs-22 Luc Teirlinck
2005-11-05 10:26 ` Eli Zaretskii
2005-11-05 15:52   ` Luc Teirlinck
2005-11-05 16:43     ` Eli Zaretskii
2005-11-05 17:33       ` Drew Adams
2005-11-05 19:46         ` Eli Zaretskii
2005-11-05 20:38           ` Drew Adams
2005-11-05 22:10             ` Luc Teirlinck
2005-11-05 23:00             ` Kim F. Storm [this message]
2005-11-05 23:18               ` Lennart Borgman
2005-11-05 23:28                 ` Luc Teirlinck
2005-11-05 23:37                   ` Lennart Borgman
2005-11-05 23:31                 ` Drew Adams
2005-11-05 23:36                   ` Drew Adams
2005-11-05 23:39                   ` Lennart Borgman
2005-11-05 23:21               ` Drew Adams
2005-11-06  1:57               ` Luc Teirlinck
2005-11-06  4:32                 ` Eli Zaretskii
2005-11-06  5:36                   ` Luc Teirlinck
2005-11-06 17:05                     ` Eli Zaretskii
2005-11-06 17:22                       ` David Kastrup
2005-11-06 18:43                         ` Eli Zaretskii
2005-11-06 18:31                       ` Luc Teirlinck
2005-11-06 18:46                         ` Eli Zaretskii
2005-11-07  9:45                           ` Alan Mackenzie
2005-11-07 20:43                             ` Eli Zaretskii
2005-11-07 20:58                             ` Eli Zaretskii
2005-11-07 21:54                         ` Richard M. Stallman
2005-11-06 20:16                       ` Luc Teirlinck
2005-11-06 22:54                         ` Kim F. Storm
2005-11-06 18:47                     ` Kim F. Storm
2005-11-06 19:19                       ` Luc Teirlinck
2005-11-07  7:04                       ` Luc Teirlinck
2005-11-07 21:55                       ` Richard M. Stallman
2005-11-06  9:19                   ` David Kastrup
2005-11-05 17:39       ` Luc Teirlinck
2005-11-06 17:02     ` Stefan Monnier
2005-11-06 17:08       ` Eli Zaretskii
2005-11-06 19:55       ` Luc Teirlinck
2005-11-05 23:43 ` Richard M. Stallman
2005-11-06  0:27   ` Luc Teirlinck
2005-11-07 15:34     ` Richard M. Stallman
2005-11-07 17:54       ` Drew Adams
2005-11-07 18:56         ` Stefan Monnier
2005-11-07 19:25           ` Drew Adams
2005-11-07 22:39           ` Lennart Borgman
2005-11-07 20:52         ` Eli Zaretskii
2005-11-07 22:59           ` Drew Adams
2005-11-08  4:47             ` Eli Zaretskii
2005-11-08  4:58       ` Luc Teirlinck
2005-11-08 12:48         ` Kim F. Storm
2005-11-08 23:53           ` Miles Bader
2005-11-09  0:21             ` Lennart Borgman
2005-11-11  7:42         ` Richard M. Stallman
2005-11-11  9:29           ` Kim F. Storm
2005-11-11 10:57             ` Miles Bader
2005-11-11 16:16               ` Kim F. Storm
2005-11-12  3:38               ` Richard M. Stallman
2005-11-12  3:15           ` Luc Teirlinck
2005-11-12 17:49             ` Richard M. Stallman
2005-11-12  3:36           ` Luc Teirlinck
2005-11-12 21:19             ` Juri Linkov
2005-11-14  4:55               ` Richard M. Stallman
2005-11-15  0:52                 ` Juri Linkov
2005-11-15 23:22                   ` Richard M. Stallman
2005-11-17  7:38                     ` Juri Linkov
2005-11-17 10:06                       ` Kim F. Storm
2005-11-09 23:25       ` Kim F. Storm
2005-11-10  5:44         ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3irv6em4c.fsf@kfs-l.imdomain.dk \
    --to=storm@cua.dk \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).