On Fri, Nov 16, 2012 at 10:06 PM, Felipe Contreras <felipe.contre...@gmail.com> wrote: > On Fri, Nov 16, 2012 at 9:54 PM, SZEDER Gábor <sze...@ira.uka.de> wrote: >> On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote: >>> So that it's easier to understand what it does. >>> >>> Also, make sure we pass only the first argument for completion. >>> Shouldn't cause any functional changes because run_completion only >>> checks $1. >>> >>> Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com> >>> --- >>> t/t9902-completion.sh | 6 +++++- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh >>> index cbd0fb6..5c06709 100755 >>> --- a/t/t9902-completion.sh >>> +++ b/t/t9902-completion.sh >>> @@ -54,10 +54,14 @@ run_completion () >>> __git_wrap__git_main && print_comp >>> } >>> >>> +# Test high-level completion >>> +# Arguments are: >>> +# 1: typed text so far (cur) >> >> Bash manuals calls this the current command line or words in the >> current command line. I'm not sure what you mean with '(cur)' here. > > The current _word_ text typed so far. > >> The variable $cur in the completion script (or in bash-completion in >> general) is something completely different. > > I believe bash's completion, this test, and the whole git completion > stuff uses the same definition of 'cur'.
Oops, actually in this particular helper this is not actually 'cur'. I think 'command line' might be more appropriate. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html