Re: new apropos feature in Emacs-22

[Luc Teirlinck <teirllm@dms.auburn.edu>]

   I looked at the previous discussion, and it seems to me that the
   only change we need is in doc strings, prompts, and argument names.
   Here's what I am thinking of installing.

The help echos in `menu-bar-apropos-menu' (Help -> Search Documentation)
and the Info nodes (emacs)Help, (emacs)Help Summary and (emacs)Apropos
would also need updating and/or clarification.  I guess (emacs)Apropos
should wait until we have decided on the final details.

   Perhaps we should change the criteria so that a period does
   not make it a regexp.  A different criterion would be ok
   as long as it is simple.

I grepped for `apropos' in the lisp directory.  I now believe that
making the default recognize even less regexps carries a risk of
breaking some things, relatively close to a release.  There were tons
of complex matches and I do not have the time to try to understand all
of them and see what would break them.

I believe that (emacs)Apropos should _explicitly_ warn that, if one
wants to search by keywords, keywords should not contain regexp special
characters and warn in particular that filenames containing dots can
normally not be used as keywords.  As people will sometimes _want_ to
use things like .emacs, .mailrc or .XDefaults as keywords, especially
for apropos-documentation, some escape convention should be provided.
Why not use my original proposal: final unquoted `[' (or final single
`\') is ignored and means that the input is unconditionally a list of
keywords, for this specialized (but real) need?

If we are willing to make somewhat more changes, there could be a user
option `apropos-search-style' whose default value nil could be the
present default with the `[' escape convention added.  There would
also be values 'keyword and 'regexp for keyword only and regexp only.
If we are willing to do somewhat more, then M-r could be unbound for
the nil value and toggle between the two other values.

I believe that, certainly with the M-r binding available, most people
knowing about the option would set it to one of the two non-nil values.
But I would guess that a default of 'regexp (which would be 100%
backward compatible) will probably be deemed unacceptable and (unlike
before my grepping) I now am afraid that an all keyword default would
break several things.

Sincerely,

Luc.