[Top][All Lists]

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

RE: new apropos feature in Emacs-22

From: Drew Adams
Subject: RE: new apropos feature in Emacs-22
Date: Mon, 7 Nov 2005 11:25:32 -0800

    > I argued that the old and new syntaxes and behaviors should
    be implemented
    > in different commands.  That would give all users what they
    want, without
    > the complexities of modes and mixed syntaxes.  It would also
    not break any
    > existing code.

    Having separate commands means that you can't have both behaviors on the
    same key-binding.  I like using the keybindings, and I sometimes need
    regexps but generally prefer the keyword search.  That's the main reason
    why I'm proposing the M-r solution.

A good argument - worth stating explicitly for the discussion. Thx.

I guess I'd still prefer that we offer separate commands, with the built-in
bindings going to the novice-friendly commands. But I agree that key-binding
is a good argument for not using separate commands.

I prefer separate commands because I think we're asking for trouble by
mixing two radically different input syntaxes - especially if we're worried
about novices.

Although radically different, the syntaxes have some overlap (even if that
sounds paradoxical). They can seem the same (with similar behavior) in some
common cases, as others have pointed out, but they are not the same.
Sometimes, les faux amis are worse than les enemis, because of the
additional element of confusion.

    I'd argue that the M-r solution should also be added to query-replace,

Do you mean for regexp vs literal input? I don't disagree with some such a
toggle. In fact, I use a command (bound to M-%) that works this way:

 - No PREFIX argument (nil) means replace literal string matches.

 - Positive PREFIX argument means replace word matches.

 - Negative PREFIX argument means replace regexp matches.

So, you see that I'm not insensitive to the single-key-binding argument.

Anyway, this is changing the subject; it should be a separate thread, if

reply via email to

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