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

["Drew Adams" <drew.adams@oracle.com>]

> > 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.

No, there are plenty of other annoyances/surprises for users in this new
behavior, besides the `*' buffer one. I gave two good examples in the report for
bug #1512, neither involving wildcards or necessarily buffers.

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1512

Beyond the multiple possibilities of surprise or confusing behavior, what's the
hurry? Why bend over backwards to force this upon users as the new default
behavior? Even if we take as given that the new behavior is interesting and can
be useful, why the need to suddenly switch to this behavior?

What's wrong with offering this as an option? There already is a user option
that controls this. All that's needed is to change the default value of that
option to the singleton list '(basic), to keep the traditional behavior as the
default.

We can then also document well the possibility of the new behavior that combines
basic with partial completion etc. - nothing wrong with advertizing this. What's
wrong is to make it the default with no track record, no discussion, no poll.