[Top][All Lists]

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

bug#9591: 24.0.50; buffer name completion

From: Drew Adams
Subject: bug#9591: 24.0.50; buffer name completion
Date: Sun, 25 Sep 2011 11:45:05 -0700

> Partial completion is too powerful.  Perhaps some extension of the
> builtin completion is desirable by default, but this is too much.


It is not so much that it is too "powerful", but that it can lead to unexpected
and wildly off-the-mark completion candidates (as you point out from time to
time, apparently with new surprise each time).

The other problem, which compounds this problem, is that multiple types of
completion/matching are tried, one after the other, in hopes of finding

The default list of matching types includes partial completion.  When a whole
set of completion types (including partial) is tried in sequence, the result can
be even more disorienting than is the result of partial completion on its own.

Instead of letting a user know that a given type of matching has come up with
`[No match]', and thus letting the user decide what to do about that (e.g. try a
different type of matching - or not), it automatically assumes that the user
wants to complete the current input at all costs, so it blithely moves on to the
next type of matching in the list...

To me, it's an overly clever misfeature.

The user has no control over this, other than customization of the list of
matching types to be used automatically.  Such a choice of matching method /
completion style should not be just a customization-time option.

Better would be to have only one kind of completion used at a time (no automatic
sequencing), and let users hit a minibuffer key (i.e., on demand) to change to
the next completion type.

IOW, let users choose at completion time which completion style(s) to use, on
demand.  Each time they change methods they can complete anew and find out
whether there are matches using that method.

The info `[No match]' is often helpful to users.  By silently skipping over
match failures, quietly moving on to try other, entirely different types of
matching, we do users a disservice.  Better to give them feedback about match
failures, and give them (dynamic) control over which matching mechanism to use
at any time.

reply via email to

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