{"thread":{"id":"33549","subject":"[QUERY] Why do we have git-completion.zsh?","startedAt":"2013-04-20T09:39:51Z","lastAt":"2013-04-21T06:56:20Z","messageCount":8,"participants":["Ramkumar Ramachandra","Jonathan Nieder","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"214906","messageId":"CALkWK0=NrJ-9mxSkOBw=kJ0CTJLUFNWBoGdqGcHEU6YqR-foFg@mail.gmail.com","threadId":"33549","inReplyTo":null,"subject":"[QUERY] Why do we have git-completion.zsh?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-20T09:39:51Z","receivedAt":"2013-04-20T09:39:51Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI realize that we maintain a bash completion script, and a thin\nwrapper around it for ZSH. However, I don't understand why we\nmaintain it, because there's a comprehensive first-class completer in\nZSH core [1] which I use all the time. Shouldn't the completion folks\nbe contributing to this instead?\n\nThanks.\n\n[1]: https://github.com/zsh-users/zsh/blob/master/Completion/Unix/Command/_git\n"},{"id":"214938","messageId":"20130420184539.GA8586@elie.Belkin","threadId":"33549","inReplyTo":"CALkWK0=NrJ-9mxSkOBw=kJ0CTJLUFNWBoGdqGcHEU6YqR-foFg@mail.gmail.com","subject":"Re: [QUERY] Why do we have git-completion.zsh?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-20T18:45:39Z","receivedAt":"2013-04-20T18:45:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRamkumar Ramachandra wrote:\n\n> However, I don't understand why we\n> maintain it, because there's a comprehensive first-class completer in\n> ZSH core [1] which I use all the time. Shouldn't the completion folks\n> be contributing to this instead?\n\nOnly if they want to.\n\nKind regards,\nJonathan\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024\n"},{"id":"214939","messageId":"20130420185329.GB8586@elie.Belkin","threadId":"33549","inReplyTo":"20130420184539.GA8586@elie.Belkin","subject":"Re: [QUERY] Why do we have git-completion.zsh?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-20T18:53:29Z","receivedAt":"2013-04-20T18:53:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n\n>> However, I don't understand why we\n>> maintain it, because there's a comprehensive first-class completer in\n>> ZSH core [1] which I use all the time. Shouldn't the completion folks\n>> be contributing to this instead?\n>\n> Only if they want to.\n[...]\n> http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024\n\nSorry, wrong link. Here's a better one:\n\nhttp://www.zsh.org/mla/workers/2011/msg00497.html\n\nMore fundamentally, your question seems to assume some kind of shared\nplan regarding what people work on, rather than each person choosing\nto work on what they consider valuable without having to justify it to\nothers. I am very happy with Felipe's work on git's completion code\nand don't think it does any harm to efforts elsewhere.\n\nThanks for your interest,\nJonathan\n"},{"id":"214946","messageId":"CAMP44s3yCW-pHVHc9WfL1BC7BKmnXxZ1WQyPRAMnx967=74_Kg@mail.gmail.com","threadId":"33549","inReplyTo":"20130420185329.GB8586@elie.Belkin","subject":"Re: [QUERY] Why do we have git-completion.zsh?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-20T22:39:31Z","receivedAt":"2013-04-20T22:39:31Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder wrote:\n> Jonathan Nieder wrote:\n>> Ramkumar Ramachandra wrote:\n>\n>>> However, I don't understand why we\n>>> maintain it, because there's a comprehensive first-class completer in\n>>> ZSH core [1] which I use all the time. Shouldn't the completion folks\n>>> be contributing to this instead?\n>>\n>> Only if they want to.\n> [...]\n>> http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024\n>\n> Sorry, wrong link. Here's a better one:\n>\n> http://www.zsh.org/mla/workers/2011/msg00497.html\n>\n> More fundamentally, your question seems to assume some kind of shared\n> plan regarding what people work on, rather than each person choosing\n> to work on what they consider valuable without having to justify it to\n> others. I am very happy with Felipe's work on git's completion code\n> and don't think it does any harm to efforts elsewhere.\n\nTo complement the reason; the zsh folks (or perhaps it's only one; who\nworks on the git stuff), absolutely prioritize \"correctness\" over\nspeed, that means if it takes ten seconds to list all the possible\nfiles to complete, grouped nicely, that's exactly what they'll do,\ninstead of the way the bash completion does, which lists the most\nlikely files, which takes milliseconds.\n\nI found zsh's completion unbearably slow, which is ironic; git is the\nfastest DSCM on Earth, and they blow the performance away by making\nthe completion dead slow, to the point where the completion is several\norders of magnitude slower than the actual command. To me, the whole\npoint of the completion is to make the work faster, and if the\ncompletion takes longer than me typing it, what's the point of it?\n\nAnd I'm not the only one, when I contributed this stuff to\noh-my-zsh[1] I got a very positive response.\n\nI couldn't convince them of this obvious fact, so I choose git's bash\nfast completion.\n\nI have patches to improve the zsh thin wrapper to give more\ninformation, zsh style, in a way that is superior to zsh's git\ncompletion, but I'm still not happy with them, I want the user to be\nable to configure the output so it's not totally bloated like in zsh,\nand I'm still working on it. In the mean time, I want my completion to\nbe blazingly fast, and at least as good as git's bash completion.\n\nIf they wanted my contributions, that would be awesome, but that\ndoesn't appear to be the case. And I'm kind of relieved, because zsh's\ncompletion is monstrous code, and the zsh development practices are\nnot good (e.g. all my logically independent patches get squashed into\none commit).\n\nCheers.\n\n[1] https://github.com/robbyrussell/oh-my-zsh\n\n-- \nFelipe Contreras\n"},{"id":"214952","messageId":"CAMP44s3T7aoN_X5vvA3wb0pm1djXSvjy_DzTvG3TYKXS+ZbLYQ@mail.gmail.com","threadId":"33549","inReplyTo":"CAMP44s3yCW-pHVHc9WfL1BC7BKmnXxZ1WQyPRAMnx967=74_Kg@mail.gmail.com","subject":"Re: [QUERY] Why do we have git-completion.zsh?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-21T01:21:16Z","receivedAt":"2013-04-21T01:21:16Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Apr 20, 2013 at 5:39 PM, Felipe Contreras\n wrote:\n> On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder wrote:\n>> Jonathan Nieder wrote:\n>>> Ramkumar Ramachandra wrote:\n>>\n>>>> However, I don't understand why we\n>>>> maintain it, because there's a comprehensive first-class completer in\n>>>> ZSH core [1] which I use all the time. Shouldn't the completion folks\n>>>> be contributing to this instead?\n>>>\n>>> Only if they want to.\n>> [...]\n>>> http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024\n>>\n>> Sorry, wrong link. Here's a better one:\n>>\n>> http://www.zsh.org/mla/workers/2011/msg00497.html\n>>\n>> More fundamentally, your question seems to assume some kind of shared\n>> plan regarding what people work on, rather than each person choosing\n>> to work on what they consider valuable without having to justify it to\n>> others. I am very happy with Felipe's work on git's completion code\n>> and don't think it does any harm to efforts elsewhere.\n>\n> To complement the reason; the zsh folks (or perhaps it's only one; who\n> works on the git stuff), absolutely prioritize \"correctness\" over\n> speed, that means if it takes ten seconds to list all the possible\n> files to complete, grouped nicely, that's exactly what they'll do,\n> instead of the way the bash completion does, which lists the most\n> likely files, which takes milliseconds.\n>\n> I found zsh's completion unbearably slow, which is ironic; git is the\n> fastest DSCM on Earth, and they blow the performance away by making\n> the completion dead slow, to the point where the completion is several\n> orders of magnitude slower than the actual command. To me, the whole\n> point of the completion is to make the work faster, and if the\n> completion takes longer than me typing it, what's the point of it?\n>\n> And I'm not the only one, when I contributed this stuff to\n> oh-my-zsh[1] I got a very positive response.\n>\n> I couldn't convince them of this obvious fact, so I choose git's bash\n> fast completion.\n>\n> I have patches to improve the zsh thin wrapper to give more\n> information, zsh style, in a way that is superior to zsh's git\n> completion, but I'm still not happy with them, I want the user to be\n> able to configure the output so it's not totally bloated like in zsh,\n> and I'm still working on it. In the mean time, I want my completion to\n> be blazingly fast, and at least as good as git's bash completion.\n\nActually, it's mostly there now:\nhttps://github.com/felipec/git/blob/fc/zsh/ng/contrib/completion/git-completion.zsh\n\nThis greatly improves 'git ' over the plain bash version, and\nit's even better than the official zsh version, because you can do\nsomething like:\n\n zstyle ':completion:*:*:git:*' tag-order 'common-commands porcelain-commands'\n\nTo show only the command groups you are interested on. With official\nzsh, you get the whole enchilada of all the commands git has. Hardly\nuser-friendly.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214956","messageId":"CALkWK0=ay452TbW-O+uBwqqMjLgeYw0V-j67vvzMqtVO-PnrXw@mail.gmail.com","threadId":"33549","inReplyTo":"CAMP44s3yCW-pHVHc9WfL1BC7BKmnXxZ1WQyPRAMnx967=74_Kg@mail.gmail.com","subject":"Re: [QUERY] Why do we have git-completion.zsh?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-21T04:36:05Z","receivedAt":"2013-04-21T04:36:05Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> To complement the reason; the zsh folks (or perhaps it's only one; who\n> works on the git stuff), absolutely prioritize \"correctness\" over\n> speed, that means if it takes ten seconds to list all the possible\n> files to complete, grouped nicely, that's exactly what they'll do,\n> instead of the way the bash completion does, which lists the most\n> likely files, which takes milliseconds.\n\nI see. Yes, I was looking for a reason like this.\n\nTrue. I've noticed that my shell just hangs when I attempt to\ntab-complete too early/ something wrong, and this would be nice to\nfix. Does it have to be a hard trade-off between correctness and\nspeed? Is it not possible to reach a fair compromise?\n\nNow, I don't know anything about zsh's git completer versus the\ngitfast completer. From a glance, it looks like zsh's git completer\nis much larger and stuffed with features that the gitfast completer\ndoesn't have. Although I agree that speed isn't the only parameter,\ncan you shed some light on how these two compare on other parameters?\n\nOr you could help me figure all this out myself. How do I\nprofile/debug shell code? I'm feeling a little lost without gdb and\nvalgrind.\n\n> And I'm not the only one, when I contributed this stuff to\n> oh-my-zsh[1] I got a very positive response.\n\nFound it: https://github.com/robbyrussell/oh-my-zsh/commit/5a11228\n\n> If they wanted my contributions, that would be awesome, but that\n> doesn't appear to be the case. And I'm kind of relieved, because zsh's\n> completion is monstrous code, and the zsh development practices are\n> not good (e.g. all my logically independent patches get squashed into\n> one commit).\n\nI see. I've just started poking them with patches. I'll see what\nhappens for myself.\n\nCheers.\n"},{"id":"214960","messageId":"CAMP44s0e=RTC_-JeFXxrdQ9Zhe8riqWKwdeae6rgwJccr_=7iA@mail.gmail.com","threadId":"33549","inReplyTo":"CALkWK0=ay452TbW-O+uBwqqMjLgeYw0V-j67vvzMqtVO-PnrXw@mail.gmail.com","subject":"Re: [QUERY] Why do we have git-completion.zsh?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-21T06:21:19Z","receivedAt":"2013-04-21T06:21:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Apr 20, 2013 at 11:36 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> To complement the reason; the zsh folks (or perhaps it's only one; who\n>> works on the git stuff), absolutely prioritize \"correctness\" over\n>> speed, that means if it takes ten seconds to list all the possible\n>> files to complete, grouped nicely, that's exactly what they'll do,\n>> instead of the way the bash completion does, which lists the most\n>> likely files, which takes milliseconds.\n>\n> I see. Yes, I was looking for a reason like this.\n>\n> True. I've noticed that my shell just hangs when I attempt to\n> tab-complete too early/ something wrong, and this would be nice to\n> fix. Does it have to be a hard trade-off between correctness and\n> speed? Is it not possible to reach a fair compromise?\n\nIt doesn't matter, the zsh folks don't want *any* compromise:\nhttp://article.gmane.org/gmane.comp.shells.zsh.devel/22475\n\n> Now, I don't know anything about zsh's git completer versus the\n> gitfast completer. From a glance, it looks like zsh's git completer\n> is much larger and stuffed with features that the gitfast completer\n> doesn't have. Although I agree that speed isn't the only parameter,\n> can you shed some light on how these two compare on other parameters?\n\nFirst of all, 'gitfast' is just the name I gave to the oh-my-zsh\nplugin that uses git.git's completion stuff. The zsh support in git's\nbash completion has been working for years, I just copied the stuff to\noh-my-zsh so those guys can use it easily. I also added my thin zsh\nwrapper, because of issues with zsh's bash completion emulation, but\nthat's not specific to oh-my-zsh in any way.\n\nSecondly, I don't see what \"features\" zsh's git completer might have\nthat we don't. Yes, some specific argument behaviors are nice, like\nadding a '=' after --git-dir, and then complete only directories, and\ncompletion descriptions, along with tag groupings, but all those\nthings are cosmetic, and they could be added relatively easy to my\nthin wrapper (which wouldn't be so thin after all). It's mostly grunt\nwork, not something that requires a great mind.\n\nFunctionally I don't see any value.\n\nFor example, a difference is that when you do 'git show v',\ngit.git bash's completion will show refs, and only if there aren't any\nthat could match, show files, any files. zsh's version will show both\nfiles and refs at the same time, and if you have grouping enabled they\nwould show that way, in the git.git repo I see them grouped in commit\ntag, tag, 'cached file' (although showing tags twice is probably a\nbug), and only the files present in the repository.\n\nAnother one is that when you do 'git add ', you see the results\ngrouped for example in 'modified file', 'untracked file', whereas in\nbash they can't be grouped.\n\nAre these minor features worth all this slowness and complicated code?\nI don't think so.\n\nAlso, the grouping requires a configuration like:\nzstyle ':completion:*:descriptions' format '%B%d%b'\nzstyle ':completion:*' group-name ''\n\nAnd I bet most people don't have such configuration. So all this\ncomplicated code achieves nothing for the majority of users.\n\nThe reason why I prefer git.git's bash completion is that it has taken\nyears to develop, and using good development practices, borrowed from\nthe mainline git process. Many more people use them, have debugged\nthem through the years, and optimized them. It's relatively small\n(compared to zsh's version), much more readable, and it even has tests\n(which I helped to start), and it's much less buggy. It's basically\nrock solid.\n\nJust now I was reading about a bug in zsh-workers when you do 'git\nshow v3' in the Linux kernel git tree, and you can count the\nseconds before it completes. This is the sort of thing that just\ndoesn't happen with git's bash completion.\n\n> Or you could help me figure all this out myself. How do I\n> profile/debug shell code? I'm feeling a little lost without gdb and\n> valgrind.\n\nFor git.git's bash completion I just run a script that exercises the\nfunction I'm interested in with perf. Fortunately nothing there is\nreally slow, so I don't have to track offenders (usually).\n\nUnfortunately zsh's completion stuff can't be scripted, or at least I\nhaven't managed to find a way to either profile or write tests for any\nof that code.\n\n>> If they wanted my contributions, that would be awesome, but that\n>> doesn't appear to be the case. And I'm kind of relieved, because zsh's\n>> completion is monstrous code, and the zsh development practices are\n>> not good (e.g. all my logically independent patches get squashed into\n>> one commit).\n>\n> I see. I've just started poking them with patches. I'll see what\n> happens for myself.\n\nYeah, I did contribute patches myself too. As long as they are\nsuperficial, like adding a missing argument or so, they are fine. But\ndon't try messing with their precious \"completeness\".\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214965","messageId":"CALkWK0khqsPurJpeXjsBGbXi--1T+88w9edbSRCFSO75nUcUZw@mail.gmail.com","threadId":"33549","inReplyTo":"CAMP44s0e=RTC_-JeFXxrdQ9Zhe8riqWKwdeae6rgwJccr_=7iA@mail.gmail.com","subject":"Re: [QUERY] Why do we have git-completion.zsh?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-21T06:56:20Z","receivedAt":"2013-04-21T06:56:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> First of all, 'gitfast' is just the name I gave to the oh-my-zsh\n> plugin that uses git.git's completion stuff. The zsh support in git's\n> bash completion has been working for years, I just copied the stuff to\n> oh-my-zsh so those guys can use it easily.\n\nYeah, I know. I just used the name.\n\n> Secondly, I don't see what \"features\" zsh's git completer might have\n> that we don't. Yes, some specific argument behaviors are nice, like\n> adding a '=' after --git-dir, and then complete only directories, and\n> completion descriptions, along with tag groupings, but all those\n> things are cosmetic, and they could be added relatively easy to my\n> thin wrapper (which wouldn't be so thin after all). It's mostly grunt\n> work, not something that requires a great mind.\n>\n> Functionally I don't see any value.\n\n> Are these minor features worth all this slowness and complicated code?\n> I don't think so.\n\nMoved to using git.git's completer, and I see that you're absolutely\nright about the \"minor features\" missing part. I just assumed that\nzsh's completer must be more complete because it's so much larger than\ngit.git's bash/zsh completer. Working backwards from zsh's completer\nwould've been a nightmare.\n\n> The reason why I prefer git.git's bash completion is that it has taken\n> years to develop, and using good development practices, borrowed from\n> the mainline git process. Many more people use them, have debugged\n> them through the years, and optimized them. It's relatively small\n> (compared to zsh's version), much more readable, and it even has tests\n> (which I helped to start), and it's much less buggy. It's basically\n> rock solid.\n\nGreat! I'll stop working on zsh's completer immediately, and try to\nredirect my attention on improving git.git's completer instead.\n\nThanks for the information.\n"}]}