[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: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.)
> > `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.