On Sat, Nov 17, 2012 at 11:56 AM, SZEDER Gábor <sze...@ira.uka.de> wrote:
> On Fri, Nov 16, 2012 at 10:46:16PM +0100, Felipe Contreras wrote:

>> But even in that case, if push comes to shoves, this zsh wrapper can
>> ultimately read COMPREPLY and figure things backwards, as even more
>> previous versions did:
>> http://article.gmane.org/gmane.comp.version-control.git/189310
> Even better.  I was just going to propose that zsh's completion could
> just read the contents of COMPREPLY at the end of _git() and _gitk(),
> because this way no zsh-induced helper functions and changes would be
> needed to the completion script at all.

I would rather modify the __gitcomp function. Parsing COMPREPLY is too

> However, running the completion script with Bash would also prevent
> possible issues caused by incompatibilities between the two shells
> mentioned below.

It could, but it doesn't now.

>> >> This is the equivalent of what Marc is doing, except that zsh has no
>> >> problems running bash's code. Note there's a difference with zsh's
>> >> emulation bash (or rather bourne shell, or k shell), and zsh's
>> >> emulation of bash's _completion_. The former is fine, the later is
>> >> not.
>> >
>> > There are a couple of constructs supported by Bash but not by zsh,
>> > which we usually try to avoid.
>> Yes, and is that a big deal?
> Not that big, but I wanted to point out that it's not "fine" either.
> Just a slight maintenance burden, because we have to pay attention not
> to use such constructs.

Do we have to pay attention?

I say when we encounter one of such maintenance burden issues _then_
we think about it. In the meantime for all we know sourcing bash's
script from zsh is fine.

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to