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

[Bastien <bzg@altern.org>]

Drew Adams <drew.adams@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