[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not w
bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
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.