On Wed, Feb 14, 2018 at 10:15 PM, SZEDER Gábor <szeder....@gmail.com> wrote:
> On Fri, Feb 9, 2018 at 12:02 PM, Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
>> diff --git a/contrib/completion/git-completion.bash
>> index c7b8b37f19..60127daebf 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1835,7 +1835,7 @@ _git_notes ()
>> case "$subcommand,$cur" in
>> - __gitcomp '--ref'
>> + __gitcomp_builtin notes
>> case "$prev" in
> Hmm, after this patch is applied, this part of _git_notes() looks like
> case "$subcommand,$cur" in
> case "$prev" in
> __gitcomp "$subcommands --ref"
> Note that '--ref' option passed to __gitcomp() along with the
> It would be great if that option could come from parse options as well,
Yeah. This is where Eric's option annotation thingy comes in very
handy. If we can tell git-completion.bash that "--ref takes a ref",
then we can do __git_complete_refs automatically.
I'm not so sure how to fit all things together yet. Just like you said
below __gitcomp_builtin is very much completing options, not values.
Worst case scenario, --git-completion-helper could generate the whole
"case" block to be eval'd here, but that also means non-bash
completion is left out.
So I'm not going to do anything about this yet. Not until I study some
more (and your notes here are very helpful)
> but we can't rely on $__gitcomp_builtin_notes being already initialized
> at this point and the current __gitcomp_builtin function tightly couples
> initializing that variable and completing options.