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

[Drew Adams <drew.adams@oracle.com>]

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