emacs-devel
[Top][All Lists]
Advanced

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

new apropos feature in Emacs-22


From: Luc Teirlinck
Subject: new apropos feature in Emacs-22
Date: Fri, 4 Nov 2005 21:15:45 -0600 (CST)

>From `(emacs)Apropos':

    Because `C-h a' looks only for commands matching the string you
    specify, you may not find what you want on the first try.  In that
    case, don't just give up.  You can give Apropos a list of words to
    search for.  When more than one word is specified, at least two of
    those words must be present for an item to match.  If you are looking
    for commands to kill a chunk of text before point, try `C-h a kill back
    behind before <RET>'.  For even greater flexibility, you can also
    supply a regular expression to Apropos (*note Regexps::).

The described behavior is new in Emacs-22.  There are several problems
with it.

Firstly, the last sentence of the above paragraph is false.  You can
not specify any regexp: a regexp that contains spaces or tabs and that
only matches itself will be mistaken for a list of keywords, unless you
use a special trick, say using "[f]ont lock mode" instead of
"font lock mode" (but no such trick is mentioned in the Emacs manual).
This restriction might not be too bad for apropos-command and
apropos-variable, where spaces make little sense, but for
apropos-documentation (and actually sometimes also apropos-value) it
could easily confuse people used to the prior behavior.

Secondly, the "at least two matching keywords" rule seems arbitrary.
Why not use the convention that a list of keywords is specified as, say

directory folder [1

or

next directory folder [2

Where the number after `[' denotes the number of required matching
keywords and the unbalanced `[' guarantees that the convention never
overwrites a valid regexp.

If the present convention is kept unchanged, then one should at the
very least update the involved docstrings: although the Emacs manual
mentions the new behavior, apparently none of the docstrings of the
involved commands do.  All the docstrings still suggest that the
REGEXP argument will always be treated as a regular expression.

Sincerely,

Luc.




reply via email to

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