Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

        __gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
        __gitcomp_nl_append $"autosetupmerge\nautosetuprebase\n" "$pfx" "$cur_" " "

This is not a bad idea at all. I'm just afraid that we might be
leaving open ends: What happens if the $pfx isn't the same in both
cases? Who keeps track of the index "i" of COMPREPLY (it's currently a
local variable)? If we make it global, doesn't every function that
deals with COMPREPLY be careful to reset it?

I am not sure what you are worried about $pfx; what does it do when
you have strings with different prefix in COMPREPLY? If it breaks,
then the answer is "don't do it then".

Doesn't an array know its own length and give you a way to ask?

More importantly, can you see a usecase for more than two completion classes?

I am not sure why you think it is more important.

Somebody lacked forsight and designed an interface that would allow
only one "completion classes" (whatever that means) and called the
result sufficient. It has been sufficient for a long time.

Later you came, found that one was not enough, and added an inteface
that would allow only two, and called the result sufficient.  See a
pattern?

Anticipating unforseen possibilities for enhancement and preparing
an easy way to support them without overengineering is what the
"prepare an appending variant" suggestion is about, and by
definition, unforseen possibilities have not been seen yet ;-)

Imagine if one is flipping 47 topic branches from 6 contributors
whose names all begin with 'j'.  I can see that such a person would
appreciate if "git config branch.j<TAB>" did not dump all 47 topics
at once but offered "jc/ jk/ jl/ jm/ jn/ js/" instead, and then a
follow-up completion of "git config branch.jk/<TAB>" expanded to
names of topics from that single contributor "jk".  Wouldn't the way
to give these be either to return these two-letter hierarchy names
with slash as the suffix or to return list of two-letter plus a
slash with an empty suffix?  Either way, that is using something
different from a dot or a space, so that may count as the third, I
guess.

Junio C Hamano wrote:

I am not sure what you are worried about $pfx; what does it do when
you have strings with different prefix in COMPREPLY? If it breaks,
then the answer is "don't do it then".

Doesn't an array know its own length and give you a way to ask?

Right. I was just throwing counterpoints at the wall.

Imagine if one is flipping 47 topic branches from 6 contributors
whose names all begin with 'j'.  I can see that such a person would
appreciate if "git config branch.j<TAB>" did not dump all 47 topics
at once but offered "jc/ jk/ jl/ jm/ jn/ js/" instead, and then a
follow-up completion of "git config branch.jk/<TAB>" expanded to
names of topics from that single contributor "jk".  Wouldn't the way
to give these be either to return these two-letter hierarchy names
with slash as the suffix or to return list of two-letter plus a
slash with an empty suffix?  Either way, that is using something
different from a dot or a space, so that may count as the third, I
guess.

Ah, after completing branch.jk/, we would want no suffix: so the
example definitely counts as a third "completion class". I agree with
your reasoning, and will rework the series to do the _append () thing
you suggested.

Thanks.