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