Re: [PATCH] tcsh-completion re-using git-completion.bash

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 16, 2012, 21:56 UTC
Message-ID: <CAMP44s0y3UPVT+ndELaKNsWXAPG3kv-Xq_Wf6ONDF3Z99A5zMQ@mail.gmail.com>
In-Reply-To: <7vr4ntkzy4.fsf@alter.siamese.dyndns.org>

On Fri, Nov 16, 2012 at 10:20 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> SZEDER Gábor <szeder@ira.uka.de> 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