Re: [PATCH/RFC] completion: complete all possible -no-<options>

[Junio C Hamano <gitster@pobox.com>]

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> So the other half of this patch, the part in git-completion.bash, is
> to uncomplete --no- options. When you do "git checkout --<tab>",
> instead of displaying all --no- options, this patch simply displays
> one item: the --no- prefix. If you do "git checkout --no-<tab>" then
> all negative options are displayed. This helps reduce completable
> options quite efficiently.

Clever.

> Of course life is not that simple, we do have --no- options by default
> sometimes (taking priority over the positive form), e.g. "git clone
> --no-checkout". Collapsing all --no-options into --no- would be a
> regression.
>
> To avoid it, the order of options --git-completion-helper returns does
> matter. The first 4 negative options are not collapsed. Only options
> after the 4th are. Extra --no- options are always printed at the end,
> after all the --no- defined in struct option, this kinda works. Not
> pretty but works.

So, the earlier mention of "clone --no-checkout" sounded about not
losing this historical practice, but (desirabilty of magic number 4
aside) this "show first handful of --no-foo" feature is not about
historical practice but is forward looking, in the sense that you do
not mark "important" negated options in the source, which would be a
way to handle the histrical "clone --no-checkout", but let the
machinery mechanically choose among --no-foo (with the stupid choice
criterion "first four are shown").  That allows other commands to
have many --no-foo form without overwhelming the choices, but I am
not sure if it is much better than a possible alternative of only
showing --no-foo for more "important" foo's when show_gitcomp() is
asked to list all of things.  It would certainly be a more involved
solution, that might require an update to the way how the choices
are precomputed (you'd end up having to keep a separate "use this
list when completing '--no-'" in addition to the normal list).

In any case, count this as a vote to support an update in this
direction.  A quite promising work ;-)

Thanks.