Re: [PATCH v2 01/41] parse-options: support --git-completion-helper

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Feb 1, 2018, 19:16 UTC
Message-ID: <CAPig+cRWzvcDUjw7CR78nZ0cbE-mPkB1a4UZqiChR0NUKSZOVw@mail.gmail.com>
In-Reply-To: <CACsJy8D5iGVDHKoMeQjm+Seea_pTixsb8Xq6D1w17Y9M42iAPw@mail.gmail.com>

On Thu, Feb 1, 2018 at 5:21 AM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 11 quoted lines

> On Thu, Feb 1, 2018 at 4:54 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> 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).

Perhaps I'm missing something, but wouldn't filtering out those options directly in Bash require only this?

    % x='--foo --bar --snoo'
    % echo ${x/--bar}
    --foo --snoo

Show 5 quoted lines

> 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.

The filtering as illustrated above using builtin Bash functionality seems unlikely to be a source of noticeable slow down on Windows.

And, if you're concerned about it not fitting the design of __gitcomp_builtin, it's almost certainly cheap enough to do the filtering each time its needed rather than worrying about caching the filtered list. (It's hard to imagine anyone noticing a slow down of three extra ${x/} substitutions.)