GNU bug report logs - #1512
23.0.60; SPC, TAB during completion do not do word completion, prefix completion

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: <1512 <at> debbugs.gnu.org>, <emacs-pretest-bug <at> gnu.org>
Subject: bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion
Date: Fri, 12 Dec 2008 15:16:10 -0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.