On Sat, Nov 17, 2012 at 11:56 AM, SZEDER Gábor <szeder@xxxxxxxxxx> 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. > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html