File name completion glitch

File name completion glitch

[Chong Yidong]

The new partial completion style completion in Emacs 23 needs to have a
few more glitches worked out before the release.  Here's one problem
that I've observed (similar complaints have been reported before):

When I type `o' in Gnus to save a Mime attachment, I get a minibuffer
prompt like this:

  Save MIME part to: ~/_foo.txt

where _ indicates the position of the cursor.  Suppose I want to save
the file to a directory named `mystuff' in my home directory.  In Emacs
22, I can use completion:

  Save MIME part to: ~/mys_foo.txt
  [TAB]
  Save MIME part to: ~/mystuff/_foo.txt

In Emacs 23, I get this:

  Save MIME part to: ~/mys_foo.txt
  [TAB]
  Save MIME part to: ~/mys_foo.txt [No match]

This happens because the TAB now takes into account the minibuffer
contents after the cursor.

Stefan, can you suggest a way to fix this problem?

Re: File name completion glitch

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> In Emacs 23, I get this:
>
>   Save MIME part to: ~/mys_foo.txt
>   [TAB]
>   Save MIME part to: ~/mys_foo.txt [No match]
>
> This happens because the TAB now takes into account the minibuffer
> contents after the cursor.
>
> Stefan, can you suggest a way to fix this problem?

The easiest "fix" is to add `emacs22' to the last element of
`completion-styles', which causing Emacs to fall back on Emacs 22
completion rules if the Emacs 23 rules don't return a match.  Is there
any reason not to do this anyway?

Re: File name completion glitch

[Stefan Monnier]

>> In Emacs 23, I get this:
>>
>> Save MIME part to: ~/mys_foo.txt
>> [TAB]
>> Save MIME part to: ~/mys_foo.txt [No match]
>>
>> This happens because the TAB now takes into account the minibuffer
>> contents after the cursor.
>>
>> Stefan, can you suggest a way to fix this problem?

I do C-k ... TAB ... C-y
I learned to do it this way in Emacs-19 and it served me well ever since.

> The easiest "fix" is to add `emacs22' to the last element of
> `completion-styles', which causing Emacs to fall back on Emacs 22
> completion rules if the Emacs 23 rules don't return a match.  Is there
> any reason not to do this anyway?

We could do it this way or fold this behavior directly into
partial-completion.  I find it to be a misfeature in most cases, tho.
I.e. maybe the right fix is to change Gnus so that it behaves more like
C-x C-w (i.e. if you enter a directory name, the default file name is
automatically added).


        Stefan

Re: File name completion glitch

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I do C-k ... TAB ... C-y
> I learned to do it this way in Emacs-19 and it served me well ever since.

I don't want to get into a debate about usage patterns, but that's two
extra keystrokes and one extra kill-ring entry.

>> The easiest "fix" is to add `emacs22' to the last element of
>> `completion-styles', which causing Emacs to fall back on Emacs 22
>> completion rules if the Emacs 23 rules don't return a match.  Is there
>> any reason not to do this anyway?
>
> We could do it this way or fold this behavior directly into
> partial-completion.  I find it to be a misfeature in most cases, tho.
> I.e. maybe the right fix is to change Gnus so that it behaves more
> like C-x C-w (i.e. if you enter a directory name, the default file
> name is automatically added).

That would not be a good idea, because it's helpful to know what the
attachment file name is, whereas with C-x C-w it's more obvious.  I'll
go ahead and fix this by setting `completion-styles'; the emacs22
expansion will only be called as a last resort, so there's no harm
anyway.

Re: File name completion glitch

[Richard M Stallman]

    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.

Re: File name completion glitch

[Miles Bader]

Richard M Stallman <rms@gnu.org> writes:
>     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...]

Thanks,

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

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.

Re: File name completion glitch

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> This denies the value of `[No match]' in letting you know that there
> is no completion with the prefix you typed.

When point is at the end of the minibuffer text, that is still the case.

RE: File name completion glitch

[Drew Adams]

> > This denies the value of `[No match]' in letting you know that there
> > is no completion with the prefix you typed.
> 
> When point is at the end of the minibuffer text, that is 
> still the case.

No, not if some match can be found using another match method in
`completion-styles'.

The new default behavior is to try partial-completion if prefix completion
fails. And even with point at the end of the minibuffer, partial-completion can
succeed after prefix completion fails. You never see `[No match]'; instead, your
input is completed.

Just do `C-x C-f a- TAB', and see if you don't see plenty of completions
displayed, in spite of not having any file that starts with the prefix `a-'. You
lose the advantage of `[No match]' telling you there is no (prefix) match, which
often means you hit the wrong key.

Again, I'm not saying that combining partial-completion with prefix completion
is a bad thing. I'm saying only that this should not be the *default* behavior.

Re: File name completion glitch

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

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

C-/ should fix that, right?

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

Because the default is what people discover.  Features that will with a
large likelihood be considered useful by to non-specialists are better
configured on than off by default.  Otherwise, most people will not
benefit from them.

Fontlocking was one such feature.  The current completion is similar in
my book: I quite like it and would not know off-hand where to go hunting
for it.

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

Except that it does not work.

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

I think that particularly in the _pretests_ we should rather err on the
progressive than on the conservative side.  _If_ that leads to negative
feedback, we have something to base a decision on.  If we have it off by
default in the pretests, there is nothing to guess how people would like
it.

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

Pretests are a way to poll.

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

They will do and think nothing if they don't get to see the feature.

> What's the hurry? It doesn't take long for a good feature to find its
> way into common practice, especially nowadays.

Only if it is there.

-- 
David Kastrup

Re: File name completion glitch

[Stefan Monnier]

>> I think it should be disabled by default, because it is painfully
>> slow in some cases.
> Can you give concrete examples?

There's a pending bug#2445 about it with a concrete example.


        Stefan

Re: File name completion glitch

[Richard M Stallman]

    > I think it should be disabled by default, because it is painfully
    > slow in some cases.

    Can you give concrete examples?

I sent a bug report with a test case a few weeks ago.

In my home dir I type C-x C-f goho TAB and it takes 7 seconds
to get back to me.