RE: new apropos feature in Emacs-22

[Drew Adams]

    > Most of the discussion has centered on _how_ to obtain the syntax and
    > behavior of both the old (regexp) and the new (keywords)
    apropos at the same
    > time, in the same command - not on whether or not that is desirable.

    That's because everybody agreed that it was desirable.  There was no
    need to discuss that about which we were in almost perfect agreement.

I've seen at least a couple of posts that indicate support for not combining
these in the same command. But you might be right that we are in the
minority. It's hard to tell, if the question isn't discussed - which is why
I raised it.

    > So, I repeat the question:  _Why not_ leave the apropos
    > commands as they were, and create new, more "novice
    > user-friendly", keyword-search commands?  The question
    > deserves some reply, at least. It should have been addressed
    > before launching a discussion of _how_ to change the existing
    > commands.

    This question was asked and answered.  I posted the URL here.

Stefan gave a good answer (key bindings) - today. But I did not see that
question asked or answered in the thread you cited. Can you please point out
the relevant passage?

Or did you mean only this, which I quoted earlier:

 - All apropos commands should `accept the same type of "search patterns".'

I already asked if that was all you meant, or if I was missing something you
saw in the thread. I have assumed the former, for lack of a reply, but let
me ask again.

If that is the only answer in the thread to the question, then just what
constitutes an "apropos command" in this regard? Is it any command that
returns information about something? Is it any command that has "apropos" in
its name? Does it refer only to the existing set of commands with "apropos"
in their names?

When I asked why all "apropos commands" should accept the same type of
input, Kim replied that it was obviously for user-friendliness.

If the existing set of commands with "apropos" in their names continued to
accept only regexps, and a new suite of commands, called, say,
`keywords-about-'* accepted only keywords, would that not be user-friendly?

Isn't it friendlier to users to make sure that the input syntax for a
command is simple, clear-cut, and unambiguous - with no surprises? Is having
two sets of commands, clearly distinguished by name, more confusing than
making users figure out how to finagle a crossbreed syntax to get one or the
other behavior?

That said, Stefan's proposal solves the syntax problem while still using the
same command - the two syntaxes would never be mixed (active at the same
time). The only problem I see with it is the problem of a default behavior
that both:

 - is suitable for newbies (=> keyword search, by default)

and

 - doesn't break existing code (=> regexp search, by default)

If we can somehow cut that knot, we might all agree on a solution. If not,
I'd still argue for separate commands.

One thing that might work is to create new commands for users, with the
toggle behavior that Stefan described (and the default in favor of
keywords). If the names are new, that change won't affect existing code. And
we can then deprecate the interactive use of the existing apropos
functions - or at least advertise only the new commands. That last step
should satisfy those who don't want two different sets of commands.

The only loss would be the current command names, for interactive use.
"Apropos", in this context, just means "about". We might call the new
commands `about', `about-variable', `about-documentation', etc. - but that
would be a bit misleading.

On the other hand, the action involved is really just a literal keyword
lookup - a search. So, more appropriate names would be `search-symbols',
`search-variables', `search-documentation', etc.  Or, better, `find-symbols'
etc. - because symbols etc. are not searched; they are found. Newbies would
in fact be more likely to stumble upon `find-commands' than
`apropos-command'.