On Sat, Nov 17, 2012 at 12:46:27PM +0100, Felipe Contreras wrote:
> 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
Each element of COMPREPLY contains a possible completion word. What
parsing is needed to use that, that is so cumbersome?
> > 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?
Unless you don't mind possible breakages of zsh completion, yes.
> 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.
That's a cool argument, will remember it when it again comes to
refactoring the __gitcomp() tests. For now those tests work just
fine. When we encounter maintenance burden issues, like fixing a bug
requiring the same modification to all of those tests, then we'll
think about it. ;)
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