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

Ramkumar Ramachandra [off-list ref] writes:

There are situations where two classes of completions possible. For
example

  branch.<TAB>

should try to complete

  branch.master.
  branch.autosetupmerge
  branch.autosetuprebase

The first candidate has the suffix ".", and the second/ third candidates
have the suffix " ". To facilitate completions of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.

That sounds like a reasonable issue to address, but I do not quite
get why you need a new helper to do this.

If the original only knows to throw "branch." + branch names +
trailing dot into COMPREPLY[] and does so by calling gitcomp_nl,
isn't it the matter of making another call to gitcomp_nl just after
the existing call to stuff branch.autosetup* with trailing SP to
append them to COMPREPLY[]?

Ahh, is that because the eventual call to __gitcompadd() starts the
iteration starting from zero, essentially forbidding you to
incrementally adding to COMPREPLY[] from multiple callers, even
though it is called comp "add" not "replace with this single thing"?

What I am wondering is if a cleaner solution that can be reused by
later needs that may have more than two data sources (or more than
two suffixes) might be to create a variant of __gitcomp_nl that does
not clear existing entries in COMPREPLY[] array, add a helper to
clear the array, which would make the existing one to:

	__gitcomp_nl () {
        	__gitcomp_clear
                __gitcomp_nl_append "$@"
	}

and then complete branch.* using two calls to __gitcomp_*, letting
the first one clear and later one(s) accumulate:

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

Will queue as-is.

Thanks.

Junio C Hamano wrote:

        __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?

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