bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Drew Adams]

emacs -Q
 
1. Suppose that you have a command `g-spot-marks-the-spot', and you
do this, mistakenly typing `c' instead of `s': `M-x g-c SPC'

There are no word completions for `g-c'. However, instead of Emacs
saying "[No match]", many possible partial-completion matches are
shown. SPC no longer provides word completion by default. You no
longer get useful feedback letting you know that you typed the
wrong character.
 
Prior to Emacs 23, both regular prefix completion and word completion
were available by default: TAB for the former, SPC for the latter.
Partial-completion mode was optional.
 
This traditional behavior (since the beginning of Emacs) should
remain the default behavior. Users should not have to customize
`completion-styles' just to restore the standard completion.

Those who prefer that SPC perform partial completion should opt in
for it, as before. Now they would also have the choice of customizing
`completion-styles' to include `partial-completion', in addition to
the choice of turning on `partial-completion-mode'.


2. A similar problem arises for prefix (i.e. TAB) completion. If you
have a command named `in-the-final-act' and you type `g' by mistake
instead of `t': `M-x in-g TAB', then instead of Emacs letting you
know that there is no match, so you can delete the `g' and type a
`t', Emacs completes your input to `inverse-add-global-abbrev',
which is confusing and, once you figure things out, requires much
more editing to get you back on track. With multiple partial
completion matches, the problem is compounded.


Please restore the traditional Emacs completion behavior by default.
It provides helpful feedback that lets you quickly correct typos on
the fly. And it is what Emacs users are used to. Users who want
partial completion turned on can customize Emacs to get that.

 
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-24 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Stefan Monnier]

> Prior to Emacs 23, both regular prefix completion and word completion
> were available by default: TAB for the former, SPC for the latter.

Define "word completion", please,


        Stefan

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Drew Adams]

> > Prior to Emacs 23, both regular prefix completion and word 
> > completion were available by default: TAB for the former,
> > SPC for the latter.
> 
> Define "word completion", please,

What SPC does in Emacs ..., 20, 21, 22: `minibuffer-complete-word'.

From Emacs manual, node Completion Commands:

`<SPC>'
Complete up to one word from the minibuffer text before point
(`minibuffer-complete-word').  <SPC> for completion is not
available when entering a file name, since file names often include
spaces.

And by "prefix completion", I mean what TAB did in Emacs ..., 20, 21, 22.

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Stefan Monnier]

>> > Prior to Emacs 23, both regular prefix completion and word 
>> > completion were available by default: TAB for the former,
>> > SPC for the latter.
>> 
>> Define "word completion", please,

> What SPC does in Emacs ..., 20, 21, 22: `minibuffer-complete-word'.

>> From Emacs manual, node Completion Commands:

> `<SPC>'
> Complete up to one word from the minibuffer text before point
> (`minibuffer-complete-word').

That's sufficiently vague that I don't see in what way the current
behavior of SPC doesn't obey it.


        Stefan

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Drew Adams]

> From: Stefan Monnier Sent: Friday, December 12, 2008 10:57 AM
> 
> >> > Prior to Emacs 23, both regular prefix completion and word 
> >> > completion were available by default: TAB for the former,
> >> > SPC for the latter.
> >> 
> >> Define "word completion", please,
> 
> > What SPC does in Emacs ..., 20, 21, 22: `minibuffer-complete-word'.
> 
> >> From Emacs manual, node Completion Commands:
> 
> > `<SPC>'
> > Complete up to one word from the minibuffer text before point
> > (`minibuffer-complete-word').
> 
> That's sufficiently vague that I don't see in what way the current
> behavior of SPC doesn't obey it.

Quelle mauvaise foi ! Do you really want to understand, or are you trying hard
not to understand (be honest)? What part of the original bug report is not clear
to you?

You asked me to define "word completion". Did you really not know what that is?
I answered the same way the Emacs doc answers (still):
`minibuffer-complete-word'. There is nothing vague about that.

Or rather, there was nothing vague about it until now. You have radically
changed the behavior of `minibuffer-complete-word', so that (1) its behavior is
very different from what it was, by default, and (2) it can now be anything at
all, depending on how a user customizes `completion-styles'.

With that redefinition to something completely indefinite and amorphous, yes,
you can, if you want, claim that the doc description is vague - or even
meaningless now. 

But we can still take the doc to describe not the behavior but the default
behavior (that is, what the default behavior should be), and understand by that
description what we have always understood by it in the past. If the words made
sense before, the same words can make the same sense now.

The new default behavior does not correspond to that description. It is unlike
the behavior of SPC completion in Emacs from time immemorial, which the doc
describes. That traditional behavior corresponds essentially to what is now
called "basic" completion - as you well know.

If you would please simply remove `partial-completion' from the default value of
`completion-styles', then the traditional behavior would be restored, by
default: both prefix (TAB) completion and word (SPC) completion would work. As
you well know.

The Emacs doc is in fact more explicit about SPC and TAB completion, giving an
illustration:

 "<SPC> (`minibuffer-complete-word') completes like <TAB>,
 but only up to the next hyphen or space.  If you have
 `auto-f' in the minibuffer and type <SPC>, it finds that
 the completion is `auto-fill-mode', but it only inserts
 `ill-', giving `auto-fill-'.  Another <SPC> at this
 point completes all the way to `auto-fill-mode'."

There is nothing vague about this description, except that it is incomplete, not
describing what happens if there is no match. That was not deemed necessary,
because completion always informed you when there was no match.

The documented behavior is the traditional one, which is not the Emacs 23
behavior for SPC. Not in general. The traditional behavior is available only
when matches are found (as is the case for `auto-fill-mode'), not when no match
is found. And that negative feedback case is an important one.

I gave concrete, simple examples of that case, showing how the current default
behavior is very different from the previous behavior for both TAB and SPC, and
how it can present problems for users. Let me repeat the examples, in case I
wasn't clear:

1. Given a definition of a command `g-spot-marks-the-spot', which you want to
execute using `M-x' -

In Emacs ...20, 21, 22, `M-x g-c SPC' displays the message [No match], because
there are no word completions for `g-c'. There is no completion that starts with
"g-c" and is followed by at least one word-constituent character.

But in Emacs 23, `M-x g-c SPC' displays lots of partial-completion matches in
*Completions*. Partial completion, not word completion, is performed. By any
honest reading of "word completion", it is no longer happening in this case.
There is no way in which you can say that any of those displayed completions
"Complete up to one word from the minibuffer text before point". Except by
totally redefining what "up to one word" means and what it means to complete the
"text before point". That would be bad faith, not trying to understand.

2. Given the definition of a command `in-the-final-act', which you want to
execute using `M-x' -

In Emacs ...20, 21, 22, `M-x in-g TAB' displays the message [No match], because
there are no prefix completions for `in-g'. There is no completion that starts
with "in-g".

But in Emacs 23, `M-x in-g TAB' completes your input to
`inverse-add-global-abbrev', totally unrelated to the command name you are
trying to complete.

If you are honest, you will admit that the default behavior of TAB and SPC is
radically different from that in Emacs 22 and before, and that it is not what
users will expect for TAB and SPC.

In particular, when there is no match in the traditional ("basic") sense,
completing your input a la partial completion can make it much more difficult to
correct a simple typo. I gave the example of mistyping `in-g' instead of `in-t'
when trying to complete to `in-the-final-act'. A message [No match] lets you
quickly change `g' to `t' and then complete. The new default behavior instead
completes to `inverse-add-global-abbrev', which requires a lot more editing to
fix.

Some people like partial completion; others don't. Its behavior is more complex
in terms of description and expectation, and it has always been optional. There
is no call to now make the default behavior for SPC and TAB use partial
completion whenever basic completion fails to find a match. Users who want that
can always customize `completion-styles' to get what they want. 

You might think that trying different sorts of completion in case of match
failure is a great feature, but others might not think so. Please restore the
traditional behavior by default, and let users try your new feature by
customizing `completion-styles'.

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Stefan Monnier]

>> That's sufficiently vague that I don't see in what way the current
>> behavior of SPC doesn't obey it.
> Quelle mauvaise foi !

I probably spent more time on word-completion than on pretty much any
other part of minibuffer.el, so believe me I've thought about what is
word completion and my understanding of it is embedded in the current
behavior (which is very similar to partial-completion-mode's behavior).

So, no I am not "de mauvaise foi", I really honestly do not understand
how you want to interpret the above "definition" of word completion in
the context of partial completion.  There are many different ways to
interpret it, probably.  But none of them seem to match the behavior you
seem to want in your example.  So unless you explain to me what behavior
you generally expect (at least with more examples), the only answer
I can give you is "your word completion seem to dislike partial
completion, so you'll need to disable partial completion", which your
report said you did not consider as a good answer.


        Stefan

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Drew Adams]

> I probably spent more time on word-completion than on pretty much any
> other part of minibuffer.el, so believe me I've thought about what is
> word completion and my understanding of it is embedded in the current
> behavior (which is very similar to partial-completion-mode's 
> behavior).

Yes, I was sure you were aware of what "word completion" means (has always meant
in Emacs).

> I really honestly do not understand how you want to interpret
> the above "definition" of word completion in the context of
> partial completion.

Why "in the context of partial completion"? Emacs word completion is not (has
never been) partial completion. That's the point. Emacs word completion (SPC),
just like Emacs prefix completion (TAB) has always had, as part of its behavior,
the display of a [No match] message when it cannot complete a word at a time or
cannot complete a prefix. That's part of what word and prefix completion mean. 

The same is true for any particular kind of completion: failure to complete
using that completion method informs you with a message such as [No match]. 

It is that which you have removed from the default behavior, by automatically
chaining, beyond failure of word and prefix completion, to use partial
completion. Reporting a failed word or prefix completion is (has always been)
part of the behavior of SPC and TAB. The negative feedback that there are no
such completions (word or prefix) is helpful. It lets you correct typos on the
fly, as indicated by the examples I gave.

The bug report was about both word (SPC) and prefix (TAB) completion, with
examples for each. In your mails you consistently ignore TAB and dwell only on
word completion. I've addressed both in each of my mails, but you keep dropping
TAB. This is not about "interpreting" what "word completion" might mean for
Emacs 23. This is about restoring what you call `basic' completion as the
default behavior - that is, restoring the pre-Emacs 23 behavior as the default.
That means restore it for TAB as well as for SPC.

> There are many different ways to interpret it, probably.

I'm not looking for new interpretations of "word completion" or its Info
description. I'm not looking for new ways that the existing text might mean
something different "in the context of partial completion". You take word
completion, mix in partial completion, and then ask me about the Info text that
described (and still describes) only word completion - asking what it means when
partial completion gets mixed in. It was never intended to mean anything "in the
context of partial completion".

I'm asking you to take partial completion out of the default behavior - to
restore the traditional behavior by default. That should be perfectly clear from
each of the mails I've sent on this. Pretending to not understand that strains
credulity.

> But none of them seem to match the behavior you seem to want in
> your example.

My examples are nothing exotic, and the behavior I "seem to want" as the default
behavior for Emacs 23 is simply the behavior of Emacs (20, 21, 22). No automatic
fallback to partial completion when basic completion fails. I've made that
clear; please stop pretending that you don't hear or understand that. The
request is simple: restore the default behavior to the behavior Emacs has always
had.

> So unless you explain to me what behavior you generally expect
> (at least with more examples),

The behavior I expect as the default behavior is the behavior that everyone
expects: the behavior that Emacs has always had: fail with [No match] when there
is no word completion (for SPC) or no prefix completion (for TAB). Do not
automatically try, after such completion failure, to use partial completion.

> the only answer I can give you is "your word completion seem to
> dislike partial completion,

"Your word completion"? I don't have my own word completion. _Emacs_ word
completion is not partial completion. Never has been. You've taken something
that was optional and mixed it in with classic (`basic') behavior, changing the
default completion behavior to basic-or-if-that-fails-then-partial. If you claim
that that is still somehow "word completion", then it is "your word completion".
It is certainly not the word completion that Emacs has always known, and which
the manual (still) describes.

> so you'll need to disable partial completion", which your
> report said you did not consider as a good answer.

It's not about my own use. I don't often use vanilla Emacs completion anyway,
for my own use (I use Icicles). I'm concerned about vanilla Emacs (-Q), not my
use of Emacs. I'm concerned that you have changed the default completion
behavior radically, taking something that was optional for a long time (most
likely with relatively few users) and making it the default.

Just please remove `partial-completion' from the defcustom for
`completion-styles'. Normal Emacs behavior will then be restored as the default
behavior, and any users who truly want the basic-or-if-that-fails-then-partial
completion behavior can customize the option value to (basic partial-completion)
to get what they want.

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefixcompletion

[Drew Adams]

To be more exact, it seems that even what you call `basic' completion is
different from past Emacs behavior. 

It is apparently what you call `emacs21' that is closest to traditional Emacs
behavior. This comment in minibuffer.el states that
`completion-emacs22-try-completion' is a misnomer:

 ;; Merge a trailing / in completion with a / after point.
 ;; We used to only do it for word completion, but it seems to make
 ;; sense for all completions.
 ;; Actually, claiming this feature was part of Emacs-22 completion
 ;; is pushing it a bit: it was only done in minibuffer-completion-word,
 ;; which was (by default) not bound during file completion, where such
 ;; slashes are most likely to occur.

In any case, any of the following are probably close enough to the traditional
behavior, and any of them would be acceptable as the default value of
`completion-styles': 

 (basic)   ; Emacs 23 word and prefix completion
 (emacs22) ; Emacs 22 word and prefix completion
 (emacs21) ; Emacs 21 word and prefix completion

They all complete a word with SPC and complete a prefix with TAB, signalling [No
match] whenever the word or prefix completion fails.

What's not appropriate is, as is currently done, adding partial-completion into
the mix as the default value of `completion-styles':

 (basic partial-completion)

And it would make sense to change the name of `basic' to `emacs23' - it is the
Emacs 23 version of word and prefix completion.

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Stefan Monnier]

> Why "in the context of partial completion"? Emacs word completion is
> not (has never been) partial completion.  That's the point.

That's your interpretation.  The current interpretation is that SPC is
a variant of TAB which works similarly except that it stops completion
at a word boundary and adds a - or a SPC if that can enable completion.
This allows SPC to obey completion-styles.
Your interpretation basically implies that SPC can't obey
completion-styles.

> Emacs word completion (SPC),

> just like Emacs prefix completion (TAB) has always had, as part of its
> behavior, the display of a [No match] message when it cannot complete
> a word at a time or cannot complete a prefix.  That's part of what word
> and prefix completion mean.

To me the above tells me you don't want partial completion.  So turn
it off.  That's what completion-styles is for.  I changed the default
on purpose.


        Stefan

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Drew Adams]

> > Why "in the context of partial completion"? Emacs word completion is
> > not (has never been) partial completion.  That's the point.
> 
> That's your interpretation.  

My "interpretation" is just (1) what the doc says and (2) what the behavior has
always been. There is nothing interpretative in that. Nothing new and nothing
Drew in it.

> The current interpretation is that SPC is a variant of TAB
> which works similarly except that it stops completion at a
> word boundary and adds a - or a SPC if that can enable completion.

The "current interpretation"? The doc has not changed - where is this new
interpretation? You changed the default behavior and you invent a new
interpretation accordingly. OK. But that's not what the doc says, and that's not
what the behavior has always been. It's your behavior and your interpretation.

Like our dear King George W, you are The Decider, and you can redefine red as
blue. Can't argue with that, except to say that red is not really blue, even if
you rename it so.

> This allows SPC to obey completion-styles. Your interpretation
> basically implies that SPC can't obey completion-styles.

No. My "interpretation" is only what the doc says. And that does not describe
the current default behavior.

It's one thing (and a good thing) to extend the possible behaviors of SPC and
TAB to alternatives. Neither I nor the existing doc "imply that SPC can't obey
`completion-styles'". The doc needs to describe the default behavior, and it
does not describe the behavior of the current default value of
`completion-styles'. It describes what the behavior has always been before,
which is what the default behavior should still be.

Partial completion using SPC does not, as the doc says SPC should, "Complete up
to one word from the minibuffer text before point". Instead, it completes _all_
of the partial words of text before point. It completes `g-ca' to `gnus-cache'
(skipping `gnus-jog-cache', BTW) - hardly "up to one word". But you will no
doubt just redefine what "up to one word" means and what it means to complete
the "text before point".

The right thing to do is to keep the standard behavior by default, and keep the
doc as it is, adding that it describes the default behavior but, depending on
customization of `completion-styles', the actual behavior might be different.

If it turns out later that most users prefer the default behavior to become
basic + partial-completion, then we can change it at that time. That's typically
how default behavior changes in Emacs (transient mark mode, font lock,...), and
that's the right way to proceed. Change shouldn't simply be about making Emacs
act like your .emacs by default. A little more conservatism in changing
longstanding default behavior is called for. Be liberal adding new and
experimental optional features, but be conservative about changing the default
behavior.

> > Emacs word completion (SPC), just like Emacs prefix completion
> > (TAB) has always had, as part of its behavior, the display of
> > a [No match] message when it cannot complete a word at a time
> > or cannot complete a prefix.  That's part of what word and
> > prefix completion mean.
> 
> To me the above tells me you don't want partial completion.

Not as the default behavior, no. I have nothing against it being an option, as
it has always been. What is wrong with that? You have not given one argument why
we should not keep the long-standing behavior as the default. You made a
significant change without the least justifying argument. Proof by
pontification?

> I changed the default on purpose.

Yes, there has never been any doubt of that. That's not an argument why the
change is a good idea. It's your idea, sure, but why is it a good one for Emacs?
Have many users been asking for partial-completion as the default behavior? It's
been available for years. I don't see a push for it as the default, except from
you.

I gave reasons why it is a bad choice as default, showing examples of confusing
(even baffling) behavior and behavior that slows down simple typo correction.
You neither address my arguments nor provide any arguments in favor of your
change.

You summarily reject any objection to your change, just as you did when I
objected to the change in default behavior for C-x C-f from lax completion to
confirmed completion. No argument, no rebuttal to reasons given, just the simple
words "You're wrong." Fortunately, in that case others brought up the same
objection later, in a different thread, you discussed the matter a bit, and
ultimately compromised. There were not more or different arguments than those I
had already given; there were only more voices.

bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Stefan Monnier]

tag 1512 +wontfix
thanks

> which is what the default behavior should still be.

I made it clear we disagree on this.


        Stefan

Processed: Re: bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> tag 1512 +wontfix
bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion
There were no tags set.
Tags added: wontfix

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)