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

["SZEDER Gábor" <szeder@ira.uka.de>]

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 <szeder@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
> cumbersome.

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. ;)