bug#1800: 23.0.60; Changed meaning of * in buffer name completion

[Juri Linkov <juri@jurta.org>]

> And I don't think we should adopt the behavior that if there are no matches
> under some interpretation of the input then we should try another interpretation
> (and another,...). That's exactly the strategy behind the "annoyance". It can be
> useful to get feedback that your input doesn't match.
>
> To me, the thing to do is keep this new behavior as an optional feature, but not
> make it the default behavior. People who opt in for this will know what they're
> getting, and no one will be annoyed/surprised.
>
> In a future release, if people generally prefer the optional behavior, it could
> become the new default. It doesn't make sense to change the default behavior now
> to something that (a) not many users have even tried, (b) was never even
> discussed at emacs-devel, and (c) is hardly documented. (The novelty and
> sometime annoyance/surprise is the main disqualifier, of course, not the lack of
> adequate doc and discussion.)

There is no harm in a feature if it has no annoyance/surprise.  You said
in http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1757

    With the traditional behavior, if there are no buffers
    with prefix `*', you are told so immediately: [No match].
    With the new, partial-completion behavior, you are given possible
    completions that do not complete `*' in the normal way
    (as a literal prefix).

So implementing a message "[No match, type TAB again for * as a wildcard]"
will keep the traditional behavior just as you want.

-- 
Juri Linkov
http://www.jurta.org/emacs/