On Thu, Feb 1, 2018 at 4:54 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> On Wed, Jan 31, 2018 at 7:05 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>> On Thu, Feb 1, 2018 at 4:04 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>>> On Wed, Jan 31, 2018 at 6:05 AM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote:
>>>> Dangerous/Unpopular
>>>> options could be hidden with the new "NOCOMPLETE" flag.
>>>
>>> I wonder if this option should be named DANGEROUS rather than
>>> NOCOMPLETE to better reflect its intention.
>>
>> It's not only for dangerous options (I forgot to mention this in the
>> commit message, I will in v3). The --continue|--abort|--skip should
>> only show up when you are in a middle of rebase/am/cherry-pick.
>> git-completion.bash handles this case separately and only put them in
>> the completion list when appropriate. --git-completion-helper must
>> not include these or the trick done by git-completion.bash becomes
>> useless.
>>
>> Interesting. So we now have two classes of "no complete". One can't be
>> configurable (--continue|--abort|--skip) and one can. I'll use two
>> separate flags for these, though I'm not adding the configuration
>> option right now.
>
> I don't see that as convincing argument for two classes of "no
> complete". Since git-completion.bash already special-cases
> rebase/am/cherry-pick for --continue|--abort|--skip, it is not far
> fetched that that special-case treatment can be extended slightly to
> also filter out those three options from the list returned by
> --git-completion-helper.
I agree that is possible, but it's a bit tricky to do the filtering
right in bash (all options are sent back as one line instead of one
per line, which is easier to process by command line tools).
On top of that, I think we want git-completion.bash to be fast, the
more commands we execute there, the unhappier Windows users are. It is
too possible to do this kind of filtering just once, before caching.
It does not fit well to how I designed __gitcomp_builtin so I need to
sit back and see how to sort that out.
Long term though, I think we would want more and more completion logic
built in. One of those things I have in mind is to let
--git-completion-helper (or some other new option) to provide
completion for possible option values (e.g. true/false, values for
"git merge --strategy=", "git status --untrack-files="....). That may
also include completion of --continue|--abort|.. in C code, something
like this roughly
# separate command blocks because we still need to cache them in shell
if [ -f .git/rebase-apply ]; then
__gitcomp $(git $cmd --git-completion-helper=in-progress)
else
__gitcomp $(git $cmd --git-completion-helper)
fi
which means eventually we have to flag these options differently.
Having said all that, these are the things I imagine we _might_ do. I
have not really thought it through and nor do I have a clear plan
forward at this point, so they may end up being just rubbish thoughts.
> So, if that special case is handled entirely by the completion script,
> then that leaves only the "dangerous" options, which requires only a
> single flag.
--
Duy
