On Fri, Nov 16, 2012 at 10:20 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> SZEDER Gábor <szeder@xxxxxxxxxx> writes:
>
>> For zsh, perhaps?
>
> Yeah, I was wondering about that.
>
> If we make zsh completion read output from a little stub in bash
> completion, just like Felipe steered this series for tcsh, we do not
> have to worry about "zsh does not split words unless emulating a
> shell and here is a way to tell zsh to do so" kind of stuff in bash
> completion.
Do we worry about that now? If we do, the only reason is because we
hadn't had a proper wrapper, like the one I'm proposing to merge. So,
we had to put things inside if [[ -n ${ZSH_VERSION-} ]]. Those things
would move to my wrapper.
The only exception where we had to change code outside of that chunk
that I'm aware of is '8d58c90 completion: Use parse-options raw output
for simple long options', which is probably fixed in later versions of
zsh, and if not, we could always replace those functions inside my
wrapper.
> The point is not about the quality of zsh's emulation
> of (k)sh when it is run under that mode, but is about not having to
> have that logic in bash-only part in the first place.
As I said, that logic can be moved away _if_ my wrapper is merged. But
then again, that would cause regressions to existing users.
Maybe we should warn them right now that they should be using my
wrapper, and that this method of zsh support would be obsoleted. But
my wrapper probably hasn't received enough testing, so do we really
want to do that right now?
Either way, I'm confident that whatever code we need can be
consolidated in git-completion.zsh, even without having to run bash.
Cheers.
--
Felipe Contreras
--
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