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

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

> > The change to treat * as a wildcard is often a pain in the neck.
> > Such changes should not be made without polling the users first.
> >
> > Please undo this change, poll the users, and redo the change
> > if they generally want it.
> 
> This is a nice feature, but I have the same problems with it.
> Trying to switch to a killed buffer that had `*' at the beginning
> of its name (e.g. *grep*) typing `* g TAB' displays a large list
> of irrelevant buffer names.
> 
> Regular expressions allow a backslash before `*' for a literal
> character. So `\ * g TAB' could try completion literally
> without interpreting `*' as a wildcard.  But I think this would
> be inconvenient.
> 
> A better variant is to provide two-step completion.  So when there is
> no buffer matching `*g' literally then display a message like
> [No match, type TAB again for * as a wildcard]

I don't think we should start making special treatment here for buffer names.

SM> Here's another option: only treat * as a wildcard if it doesn't match
SM> anything existing.  I.e. if you have buffers that start with "*", then
SM> "*g" will not treat the * as a wildcard.  To force the use of
SM> a wildcard, we could let the user type "**g".

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