EspeonEefi wrote:
> Package: bash-completion
> Version: 20060301-2
> Followup-For: Bug #468254
>
> I can reproduce the test cases on my machine. I've attached my current
> /etc/bash_completion just to check against yours. It's the result of
> purging bash-completion and then reinstalling bash-completion, so it
> should be the maininter's version that's shipping with bash-completion.
Your version of bash_completion is indeed the same as mine.
> Running a diff between the /etc/bash_completion from bash-completion and
> the /etc/bash_completion from bash 3.1dfsg-8 shows that basically
> everywhere that had "cur=${COMP_WORDS[$COMP_CWORD]}" was replaced by
> "cur=`_get_cword`". (_get_cword() did not exist in the bash_completion
> from bash 3.1dfsg-8.) Changing references to _get_cword back to
> ${COMP_WORDS[$COMP_CWORD]} fixes the problem.
Well, apparently I don't understand what the problem is. Can you please
provide a step by step test case?
> The _get_cword is new functionality that the new bash_completion is
> trying to provide. Supposedly, by using _get_cword instead of
> ${COMP_WORDS[$COMP_CWORD]}, it will match against the current word only
> up to the insertion point instead of against the entire current word.
Yes, that's something I can reproduce. Though I don't see how that's
related to the test cases the other users submited as that only happens
when the cursor is positioned in the middle of a word instead of at the end?
> However, the new "feature" has introduced quite a regression that makes
> completion unusable if you have any number of files with spaces in their
> names.
Without being able to reproduce it I'm not so sure it's a bug in the new
feature or a bug in some part of the environment...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
