GNU bug report logs - #15980
24.3.50; `minibuffer-complete-word': case where it does not work correctly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15980 in the body.
You can then email your comments to 15980 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; `minibuffer-complete-word': case where it does not work
 correctly
Date: Tue, 26 Nov 2013 09:11:45 -0800 (PST)

Seems like the behavior is wrong in this case, but I see that the same
behavior is found for Emacs 20 through 24.  So I cannot say for sure
whether this is a bug.  At least the behavior does not seem to follow
the doc.

The doc ((emacs) `Completion Commands') says that SPC does this:

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

emacs -Q

(defun cmd\ \ \ \ w\ ith\ spaces () (interactive) (message "SPACES"))

(defun cmd-without-spaces () (interactive) (message "NOPE"))

M-x cm SPC ; correctly completes to `cmd'
SPC        ; completes to `cmd '

Since SPC is supposed to complete a word at a time, and since both ` '
and `-' are word separators, I would expect that there are two
word completions for the prefix `cmd': `cmd ' and `cmd-'.

So I would expect to see *Completions* displayed, showing the two
candidates `cmd    w ith spaces' and `cmd-without-spaces'.

Admittedly, this is a corner use case.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-11-20 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Message #8 received at 15980 <at> debbugs.gnu.org (full text, mbox):

From: Bastien Guerry <bzg <at> altern.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15980 <at> debbugs.gnu.org
Subject: Re: bug#15980: 24.3.50;
 `minibuffer-complete-word': case where it does not work correctly
Date: Tue, 07 Jan 2014 13:04:55 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

> Seems like the behavior is wrong in this case, but I see that the same
> behavior is found for Emacs 20 through 24.  So I cannot say for sure
> whether this is a bug.  At least the behavior does not seem to follow
> the doc.
>
> The doc ((emacs) `Completion Commands') says that SPC does this:
>
>   Complete up to one word from the minibuffer text before point
>   (`minibuffer-complete-word').
>
> emacs -Q
>
> (defun cmd\ \ \ \ w\ ith\ spaces () (interactive) (message "SPACES"))
>
> (defun cmd-without-spaces () (interactive) (message "NOPE"))
>
> M-x cm SPC ; correctly completes to `cmd'
> SPC        ; completes to `cmd '
>
> Since SPC is supposed to complete a word at a time, and since both ` '
> and `-' are word separators, I would expect that there are two
> word completions for the prefix `cmd': `cmd ' and `cmd-'.
>
> So I would expect to see *Completions* displayed, showing the two
> candidates `cmd    w ith spaces' and `cmd-without-spaces'.

See the first comment in `completion--try-word-completion':
the function considers that either a space *or* an hyphen will
be used to separate words.  The "or" is exclusive.

> Admittedly, this is a corner use case.

Yes -- note that TAB works fine here instead of SPC.

The only place I can think of where this could be a problem
is the info manual (`g' or `i' to go to a node or to find an
index entry.)  Still, you're not like to stumble on such case.

I'm for closing this bug until it really hit someone.

Message #11 received at 15980 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Bastien Guerry <bzg <at> altern.org>
Cc: 15980 <at> debbugs.gnu.org
Subject: RE: bug#15980: 24.3.50; `minibuffer-complete-word': case where it
 does not work correctly
Date: Tue, 7 Jan 2014 09:06:36 -0800 (PST)

> > Since SPC is supposed to complete a word at a time, and since both
> > ` ' and `-' are word separators, I would expect that there are two
> > word completions for the prefix `cmd': `cmd ' and `cmd-'.
> >
> > So I would expect to see *Completions* displayed, showing the two
> > candidates `cmd    w ith spaces' and `cmd-without-spaces'.
> 
> See the first comment in `completion--try-word-completion':
> the function considers that either a space *or* an hyphen will
> be used to separate words.  The "or" is exclusive.

`completion--try-word-completion' is an *implementation*.  If that's
what it does then it does not do what the doc says, right?  So either
the doc needs to be fixed to fit the implementation or vice versa, no?

> > Admittedly, this is a corner use case.

I meant corner case for command names.  It is not a corner case
to have space chars in completion candidates.

> Yes -- note that TAB works fine here instead of SPC.
> 
> The only place I can think of where this could be a problem
> is the info manual (`g' or `i' to go to a node or to find an
> index entry.)

Why is that the only place you can think of?  Are you saying that
because those completion candidates contain space chars?  There
are *lot* of places where Emacs can use completion for candidates
that contain space chars.  `completing-read' is completely
general.  Emacs should make no assumptions about whether completion
candidates happen to contain spaces. 

> Still, you're not like to stumble on such case.

What makes you say that?

> I'm for closing this bug until it really hit someone.

That's not right.  The product and the doc do not agree, as you
have pointed out.  That alone is a bug.  One way or another it
should be fixed.

Message #14 received at 15980 <at> debbugs.gnu.org (full text, mbox):

From: Bastien <bzg <at> altern.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15980 <at> debbugs.gnu.org
Subject: Re: bug#15980: 24.3.50;
 `minibuffer-complete-word': case where it does not work correctly
Date: Tue, 07 Jan 2014 18:14:06 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

>> > Since SPC is supposed to complete a word at a time, and since both
>> > ` ' and `-' are word separators, I would expect that there are two
>> > word completions for the prefix `cmd': `cmd ' and `cmd-'.
>> >
>> > So I would expect to see *Completions* displayed, showing the two
>> > candidates `cmd    w ith spaces' and `cmd-without-spaces'.
>> 
>> See the first comment in `completion--try-word-completion':
>> the function considers that either a space *or* an hyphen will
>> be used to separate words.  The "or" is exclusive.
>
> `completion--try-word-completion' is an *implementation*.  If that's
> what it does then it does not do what the doc says, right?  So either
> the doc needs to be fixed to fit the implementation or vice versa, no?

`completion--try-word-completion' does not have a docstring.

>> > Admittedly, this is a corner use case.
>
> I meant corner case for command names.  It is not a corner case
> to have space chars in completion candidates.

Agreed.

>> Yes -- note that TAB works fine here instead of SPC.
>> 
>> The only place I can think of where this could be a problem
>> is the info manual (`g' or `i' to go to a node or to find an
>> index entry.)
>
> Why is that the only place you can think of?  

Because my thinking is limited.

> Are you saying that
> because those completion candidates contain space chars?  There
> are *lot* of places where Emacs can use completion for candidates
> that contain space chars.  

My point is that there is little chance that *many* non-contrived
strings can be completed either as xxx- or as xxx\ (wich a space.)

> `completing-read' is completely
> general.  Emacs should make no assumptions about whether completion
> candidates happen to contain spaces.

Agreed.  I couldn't find a fix.

>> Still, you're not like to stumble on such case.
>
> What makes you say that?

Instinct.  But I can be proven wrong, of course.

>> I'm for closing this bug until it really hit someone.
>
> That's not right.  The product and the doc do not agree, as you
> have pointed out.  That alone is a bug.  One way or another it
> should be fixed.

So let's keep this open and find someone that can fix it properly.

-- 
 Bastien

Message #17 received at 15980 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Bastien <bzg <at> altern.org>
Cc: 15980 <at> debbugs.gnu.org
Subject: RE: bug#15980: 24.3.50; `minibuffer-complete-word': case where it
 does not work correctly
Date: Tue, 7 Jan 2014 09:50:17 -0800 (PST)

> >> See the first comment in `completion--try-word-completion':
> >> the function considers that either a space *or* an hyphen will
> >> be used to separate words.  The "or" is exclusive.
> >
> > `completion--try-word-completion' is an *implementation*.  If
> > that's what it does then it does not do what the doc says, right?
> > So either the doc needs to be fixed to fit the implementation or
> > vice versa, no?
> 
> `completion--try-word-completion' does not have a docstring.

I meant the doc I cited earlier.  It's not about whether that
function's behavior matches its code comment.  It's about whether
Emacs behavior matches what we tell users that behavior is.

> > Are you saying that because those completion candidates contain
> > space chars?  There are *lot* of places where Emacs can use
> > completion for candidates that contain space chars.
> 
> My point is that there is little chance that *many* non-contrived
> strings can be completed either as xxx- or as xxx\ (wich a space.)

OK.

> > `completing-read' is completely general.  Emacs should make no
> > assumptions about whether completion candidates happen to contain
> > spaces.
> 
> Agreed.  I couldn't find a fix.

Then perhaps leave it open until someone can.

One possible fix is to document the actual behavior instead of
saying what we say now.

> >> I'm for closing this bug until it really hit someone.
> >
> > That's not right.  The product and the doc do not agree, as you
> > have pointed out.  That alone is a bug.  One way or another it
> > should be fixed.
> 
> So let's keep this open and find someone that can fix it properly.

OK.  But again, if you can describe the actual behavior, perhaps
it is enough to correct what we say currently.

Message #22 received at 15980-done <at> debbugs.gnu.org (full text, mbox):

From: Bastien <bzg <at> altern.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15980-done <at> debbugs.gnu.org
Subject: Re: bug#15980: 24.3.50;
 `minibuffer-complete-word': case where it does not work correctly
Date: Wed, 08 Jan 2014 00:37:27 +0100

Hi Drew,

Drew Adams <drew.adams <at> oracle.com> writes:

> OK.  But again, if you can describe the actual behavior, perhaps
> it is enough to correct what we say currently.

This is now fixed in trunk.  Please test and report any problem.

-- 
 Bastien

Previous Next

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