On Thu, Oct 29, 2020 at 11:27 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > >> On zsh the situation is different; zsh by default has a git completion > >> (/usr/share/zsh/functions/Completion/Unix/_git), and some might argue > >> it's more complete than git's zsh completion, > > > > How is that completion script developed, maintained and distributed? > > > > By "by default" I believe you mean that it gets installed when you > > install zsh automatically. Is the situation different on macOS land > > (which I can believe, unfortunately)? > > ... > > Web searching for "zsh git autocompletion" gave a few interesting insights. > > - https://medium.com/@oliverspryn/adding-git-completion-to-zsh-60f3b0e7ffbc > was the first hit, which is about how to use what we ship in contrib/ It's weird that he didn't have completion. He probably hadn't enabled completion (in general). > - https://stackoverflow.com/questions/24513873/ which was near the top > had these gems. > The "knows out of the box" in https://stackoverflow.com/a/58517668 > is matches your "zsh by default has". This is just the tip of the iceberg. In the past people that wanted to have the Zsh default could do `brew install git --without-completions`, but the Homebrew team decided to remove that option, so now everyone gets the completions overridden by installing Git. https://github.com/Homebrew/homebrew-core/commit/f710a1395f44224e4bcc3518ee9c13a0dc850be1 > > so why would > > distribution maintainers chose the one in 'contrib' (an unofficial > > contributed script) over the official one? Indeed they don't, at least > > on Arch Linux. > > You're right. They would certainly not, and the situation is quite > different from bash completion where we seem to be the authoritative > implementation. > > This leads me in a totally different direction. > > We are making life worse for the zsh users by shipping our own > version, aren't we? If we didn't ship our own completion script for > them, the user did not have to remove the one "which is considerably > less complete/capable". No. You are assuming the opinion of one user in Stack Overflow is a fact. There's a reason people prefer to use Git's official completion, and there's a reason I wrote the wrapper. The Zsh default completion is *incredibly* slow. Just as a point of comparison when I do `git checkout <tab>` on the Linux kernel git repository, it takes *three* seconds to complete. With the Git official completion it's instantaneous, just like in Bash. This defeats the whole purpose of completion. If it takes less time for me to type the thing than it takes the completion to complete it, then the completion is useless. I explained this to the Zsh developers[1], and they didn't care. They prioritize completeness over usability. I even wrote a blog post about the issue: https://felipec.wordpress.com/2013/07/31/how-i-fixed-git-zsh-completion/ > Perhaps we are misleading users with our > version that has an implicit "came from those who know Git the best > in the world" label that gives it more authenticity than it > deserves. And perhaps not. > A good zsh autocompletion would need to be written and > reviewed by those who know zsh completion well. No. Those people don't care if their completion is unusable. Zsh users want a completion that is usable, and achieves the purpose of a completion; to make the user more productive. Not a completion Zsh developers feel proud about. > They also need to > know Git somewhat, but the expertise on the former would be a lot > more important, I would think. I disagree. To make the Git completion fast, efficient, and consistent to how Git is supposed to be used, it's much more important to know Git. For example, if you do `git <tab>` in Git's Zsh completion, you get only porcelain commands, if you do the same in Zsh's default completion, you get "check-attr" in the list, which I doubt any Git developer would consider something the user should see by default. You can do `git check-<tab>` and the Git's Zsh completion I wrote will still complete it, even though it's not visible initially. So in that sense *my* code is superior; 1) It shows only the common commands by default, 2) all commands can be completed anyway, and 3) can be configured to show aliases too, and the order can be configured too. Why didn't the Zsh default completion do this? I don't know. > But as you said in > <CAMP44s3wqxTmgQpMgk2cM33EvtwrvvXYv4_90GKGmHb8yJHAKg@xxxxxxxxxxxxxx> > > The answer is obvious: the set of zsh users and the set of git > developers don't overlap. > > this community is not equipped to give good reviews and improvement > suggestions on zsh matters to your patches. And I do not have a > feeling that the situation would change soon. Neither does any other community. But in this community at least some people try. > Do your recent 29-patch improvements not just fill the "gap" but > surpass the one that comes by default with zsh? I have this nagging > feeling that the effort to make the autocompletion better for Git > users who use zsh may be better made by you ("git blame" tells me that > you seem to be the only one who's invested heavily in the script, > unfortunately) joining forces with those who develop and maintain the > autocompletion that comes by default with zsh. This is not possible, as the Zsh maintainers don't care about usability. Plus, the whole point of my wrapper is to leverage the Bash completion, which is actively maintained. The Zsh developers would *never* agree to use the Bash completion in any capacity. The current situation is far from ideal, but I don't see any obvious way to improve it. [1] https://www.zsh.org/mla/workers/2011/msg00506.html -- Felipe Contreras
