Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()
Ramkumar Ramachandra artag...@gmail.com writes: 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? 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.jTAB 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. -- 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
Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()
Ramkumar Ramachandra artag...@gmail.com 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.
--
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
Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()
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? -- 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
[PATCH 2/4] completion: introduce __gitcomp_2 ()
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.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10 ++
2 files changed, 40 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..64b20b8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,36 @@ __gitcomp_nl ()
__gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
+# Generates completion reply from two sets of completion words, with
+# configurable suffixes for each.
+#
+# It accepts 2 to 6 arguments:
+# 1: First set of possible completion words.
+# 2: Second set of possible completion words.
+# 3: A prefix to be added to each completion word (both $1 and $2)
+#(optional).
+# 4: Generate possible completion matches for this word (optional).
+# 5: A suffix to be appended to each completion word in the first set
+#($1) instead of the default space (optional).
+# 6: A suffix to be appended to each completion word in the second set
+#($2) instead of the default space (optional).
+__gitcomp_2 ()
+{
+ local pfx=${3-} cur_=${4-$cur} sfx=${5- } sfx2=${6- } i=0
+ local IFS=$' \t\n'
+
+ for x in $1; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx
+ fi
+ done
+ for x in $2; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx2
+ fi
+ done
+}
+
# Generates completion reply with compgen from newline-separated possible
# completion filenames.
# It accepts 1 to 3 arguments:
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 6fca145..261a7f5 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -76,6 +76,16 @@ __gitcomp_nl ()
compadd -Q -S ${4- } -p ${2-} -- ${=1} _ret=0
}
+__gitcomp_2 ()
+{
+ emulate -L zsh
+
+ local IFS=$' \t\n'
+ compset -P '*[=:]'
+ compadd -Q -S ${5- } -p ${3-} -- ${=1} _ret=0
+ compadd -Q -S ${6- } -p ${3-} -- ${=2} _ret=0
+}
+
__gitcomp_file ()
{
emulate -L zsh
--
1.8.5.2.227.g53f3478
--
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
