On Thu, Feb 1, 2018 at 5:21 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Thu, Feb 1, 2018 at 4:54 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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
> 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.)
