RE: File name completion glitch

[Drew Adams]

> >     The new partial completion style completion in Emacs 23 
> >     needs to have a few more glitches worked out before the release.
> >
> > I think it should be disabled by default, because it is painfully
> > slow in some cases.
> 
> Can you give concrete examples?  Is it just when explicitly 
> used (i.e., completing something which wouldn't give any results
> with old-style completion), or does it slow down "normal"
> completion too?
> 
> [I've never noticed any obvious slowdown, and it's 
> _enormously_ useful...]

I don't care so much about the slowness. It makes sense that if Emacs keeps
trying different matching methods to find a possible completion, that will be
slower in some cases. But that's not the real problem here, IMO.

The real problem is the assumption that Emacs *should, by default*, try
additional matching methods when prefix completion fails, to see if it can't
match your input with something, somehow. 

This denies the value of `[No match]' in letting you know that there is no
completion with the prefix you typed. That simple, understandable test is no
longer the test users can rely on. Their conceptual model of completion must now
be more complex.

I think this should be disabled by default because it prevents users from
getting useful, immediate feedback of a non-match (in the usual, prefix sense).
Instead, it searches for a match in additional ways, and can ultimately come up
with a "match" that can be confusing, unexpected, and not helpful.

Immediate feedback that you hit the wrong key lets you correct the typo on the
spot. Instead, giving you some inappropriate completion (according to unexpected
new matching criteria) makes you wonder "WTF?!" and then go out of your way to
remove the completed text and retype what you meant. See the URLs below for real
examples of such inappropriate completions.

I don't deny that some people will find the extra, non-vanilla match-trying
useful ("_enormously_" or otherwise). But let users who do find it so customize
option `completion-styles' to add non-vanilla matching methods - no big deal.
The new feature makes it simple for them to do that; why impose it on everyone
by default?

Leave the default behavior as it's always been. But advertise as loudly as you
like the possibility of customizing `completion-styles' to add additional
matching methods (e.g. partial-completion) at will. That's a reasonable way to
introduce something like this.

After time, if it turns out that most *users* prefer to change the behavior to
include additional matching methods, we can change the default then. At that
point, based on experience and user input, we can discuss what the best default
mix of completion styles might be (including styles yet to be defined, no
doubt).

IOW, let people try the new behavior as an option, and then let the users help
us decide, based on their experience - just as we have done traditionally.

Several users, including RMS, have reported the new, confusing behavior as a
bug, to which Stefan has declared "not a bug; it's a feature". Yes, it was
intentional. Yes, it (trying to match using multiple completion styles) is a
good feature to add. No, it's not a good idea to make it the *default* behavior.

See:
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1800#80

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

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

AFAICT, in all of that discussion, no argument beyond that's-what-I-want was
ever given for why we must change the default. Good arguments (with supporting
examples) were given against changing the default.

And this significant change was made, AFAICT, without any proposal or discussion
in emacs-devel. How many of you were even aware of it? People seem to become
aware of it individually, by falling upon gotchas. (It is hardly documented.)

Richard said, "Please undo this change, poll the users, and redo the change if
they generally want it."  

I say, please undo this change, and wait to see what the users do and think
after some time.

What's the hurry? It doesn't take long for a good feature to find its way into
common practice, especially nowadays. If after a while everyone is asking to add
additional completion styles to the *default* behavior, we can do that then, and
we can pick the best mix and order, based on that input and experience.