On Mon, Feb 5, 2018 at 4:56 AM, Duy Nguyen <pclo...@gmail.com> wrote:
> On Thu, Feb 01, 2018 at 02:16:46PM -0500, Eric Sunshine wrote:
>> On Thu, Feb 1, 2018 at 5:21 AM, Duy Nguyen <pclo...@gmail.com> wrote:
>> > On Thu, Feb 1, 2018 at 4:54 PM, Eric Sunshine <sunsh...@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
>
> OK how about some thing like this fixup patch? __gitcomp_builtin now
> allows to add extra options as well as remove some.
>
> -- 8< --
> __gitcomp_builtin ()
> {
> + local incl="$2"
> + local excl="$3"
> + options="$(__git ${cmd/_/ } --git-completion-helper) $incl "
> + for i in $excl; do
> + options="${options/$i /}"
Is 'options' guaranteed to end with a space? If not, then this
expulsion will fail for the very last option. I'd think you can get by
fine with just "${options/$i}".
