Felipe Contreras wrote: > To complement the reason; the zsh folks (or perhaps it's only one; who > works on the git stuff), absolutely prioritize "correctness" over > speed, that means if it takes ten seconds to list all the possible > files to complete, grouped nicely, that's exactly what they'll do, > instead of the way the bash completion does, which lists the most > likely files, which takes milliseconds. I see. Yes, I was looking for a reason like this. True. I've noticed that my shell just hangs when I attempt to tab-complete too early/ something wrong, and this would be nice to fix. Does it have to be a hard trade-off between correctness and speed? Is it not possible to reach a fair compromise? Now, I don't know anything about zsh's git completer versus the gitfast completer. From a glance, it looks like zsh's git completer is much larger and stuffed with features that the gitfast completer doesn't have. Although I agree that speed isn't the only parameter, can you shed some light on how these two compare on other parameters? Or you could help me figure all this out myself. How do I profile/debug shell code? I'm feeling a little lost without gdb and valgrind. > And I'm not the only one, when I contributed this stuff to > oh-my-zsh[1] I got a very positive response. Found it: https://github.com/robbyrussell/oh-my-zsh/commit/5a11228 > If they wanted my contributions, that would be awesome, but that > doesn't appear to be the case. And I'm kind of relieved, because zsh's > completion is monstrous code, and the zsh development practices are > not good (e.g. all my logically independent patches get squashed into > one commit). I see. I've just started poking them with patches. I'll see what happens for myself. Cheers. -- 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