bug#9591: 24.0.50; buffer name completion

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

> I find arguments about defaults a waste of time.

Echoes of those who claim political discourse and politics in general are a
waste of time...

1. This thing about user surprise/confusion and lack of control is very much
about the default behavior.  Someone who explicitly chooses something like
partial completion presumably knows what s?he's in for.  Not necessarily so,
someone using the default settings.

You might not like discussing defaults (who does?), or you might think that
doing so is a waste of time (sometimes it is), but arguing against discussing
what the default behavior should be is simply an argument defending the status
quo without giving any reason.  This is a very old story...

> I customized completion-category-overrides to nil and
> completion-styles to `(emacs22), and the result is the
> kind of completion that Richard wanted and expected.


2. That a given user such as Richard can customize away the default automatic
chaining of completion methods is not the point.  The question (I raise) is
whether the default behavior should be to chain methods together.

This was a *big* change in default behavior, beyond just the differences
provided by any of the individual fancy matching methods (e.g. partial
completion matching).  It was hardly discussed (discussion was more or less
discouraged, IMO).


3. My point in mentioning a user-controlled, on-demand approach (as, e.g., in
Icicles) is that:

3a. Users can still define the list of methods to try - exactly as is the case
now in Emacs (e.g. `completion-styles').

3b. Users can have Emacs *not* automatically chain these methods together.  They
can have Emacs use only the first (or perhaps the last-used) method, by default.

3c. Users can nevertheless switch to the next method in the list - on demand.


4. We could also let an individual item in the methods list
(`completion-styles') be itself a list of methods, as an alternative to a single
method.  When such a list item is chosen, its methods *would* be chained
together automatically.  IOW, let users decide whether and how much to use
automatic chaining.


In sum:

A. Pick as the default behavior a single, simple/basic completion method, one
with few surprises.

B. Let users, as now, customize the list of available methods.

C. Let users switch to the next method in their list on demand, by hitting a
key.

D. Let users choose (opt in) to have Emacs automatically chain among some
methods, by using a list of those methods as an entry of the methods-list option
(`completion-styles').

For example (`completion-styles' values):

(basic emacs22 partial-completion) would you give basic completion by default,
and let you cycle to Emacs 22 completion on demand (only), and then to partial
completion and then back to basic..., by hitting a key in the minibuffer.

((basic partial-completion emacs22)) would give you the current,
automatic-chaining behavior by default, and would not provide for any
alternative (no other entry to cycle to, manually)

(basic (basic partial-completion emacs22)) would give you basic completion by
default, and would let you switch to the current default behavior of automatic
chaining among basic, partial, and emacs22 on demand.

And so on.  Such an approach would give users control and flexibility.  They
could choose whether and when switching between methods should be on-demand vs
automatic.

But the important thing is for us to choose the default behavior wisely. IMO,
the default should *not* use chaining and should probably not be partial
completion.  Avoiding these would present users with fewer surprises and
gotchas, but they could still get all the bells and whistles available now - and
more - if they want.


P.S. As for polling the users, Richard said almost 3 years ago that they should
be polled for this:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1757#40