Shawn O. Pearce wrote:
>
> Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote:
> > + local i c=1 have_regex=""
> > + while [ $c -lt $COMP_CWORD ]; do
> > + i="${COMP_WORDS[c]}"
> > + case "$i" in
> > + -e) ;;
> > + -e*) have_regex="$c" ; break ;;
> > + -*) ;;
> > + *) have_regex="$c"; break ;;
> > + esac
> > + c=$((++c))
> > + done
>
> What happens with `git grep -e a -e b`? Do we trigger into ref
> completion too early when we should still be doing the regex
> completion?
Hmm, true, I would also have to check for the last argument (before
completion) being -e.
However, that is kind of moot because we currently complete filenames
anyway, and you said I can't stop that:
> > This is still RFC because, as you can see in the code below, I tried
> > to avoid completing at all while the user still needs to supply a
> > regex. Sadly, bash turns the COMPREPLY=() into filename completion
> > anyway. Is there a way to prevent this?
>
> Not that I know of. You can turn off default filename completion
> when you register the completion function, but that then breaks
> like every other git command for completion support because a lot
> of them do want to complete filenames.
So I'll roll a simpler patch that just always (before --) completes
refs instead, if that's ok.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html