| Message ID | 20190621223107.8022-1-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | completion: a bunch of updates | expand |
Felipe Contreras <felipe.contreras@gmail.com> writes: > Here's another try at completion fixes, cleanups, and more tests. Some > of these have already been sent. > > Felipe Contreras (14): > completion: zsh: fix __gitcomp_direct() > completion: zsh: fix for directories with spaces > completion: remove zsh hack > completion: zsh: improve main function selection > completion: prompt: fix color for Zsh > completion: bash: cleanup cygwin check > completion: zsh: update installation instructions > completion: bash: remove old compat wrappers > completion: bash: remove zsh wrapper > completion: zsh: trivial cleanups > test: completion: tests for __gitcomp regression > test: completion: use global config > completion: add default options > completion: add default merge strategies > > contrib/completion/git-completion.bash | 202 +++++++++++++------------ > contrib/completion/git-completion.zsh | 53 +++---- > contrib/completion/git-prompt.sh | 10 +- > t/t9902-completion.sh | 37 +++-- > 4 files changed, 161 insertions(+), 141 deletions(-) Having scanned the discussion threads so far, I think the last four patches are going against the list consensus of (1) it is OK to rely on --git-completion-helper; using ancient Git with new completion script won't obviously work, but that is "if it hurts, don't". (2) some subcommands will fail the --git-completion-helper request (e.g. outside a repository), but as long as the output from failed request is not cached, it is OK. But we haven't seen any response to the earlier zsh specific patches. Does it mean that nobody other than Felipe cares about having a working Git completion for zsh? Or does it mean that all users other than Felipe are happy with the current Git completion for zsh and it works very well for them already? Or somewhere in between? What I am trying to get at is if we would want to keep the earlier zsh parts of the series, but with nobody seemingly interested in, it is hard for me to justify queuing them. Thanks.
On Wed, Jul 03, 2019 at 10:50:26AM -0700, Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > > > Here's another try at completion fixes, cleanups, and more tests. Some > > of these have already been sent. > > > > Felipe Contreras (14): > > completion: zsh: fix __gitcomp_direct() > > completion: zsh: fix for directories with spaces > > completion: remove zsh hack > > completion: zsh: improve main function selection > > completion: prompt: fix color for Zsh > > completion: bash: cleanup cygwin check > > completion: zsh: update installation instructions > > completion: bash: remove old compat wrappers > > completion: bash: remove zsh wrapper > > completion: zsh: trivial cleanups > > test: completion: tests for __gitcomp regression > > test: completion: use global config > > completion: add default options > > completion: add default merge strategies > > > > contrib/completion/git-completion.bash | 202 +++++++++++++------------ > > contrib/completion/git-completion.zsh | 53 +++---- > > contrib/completion/git-prompt.sh | 10 +- > > t/t9902-completion.sh | 37 +++-- > > 4 files changed, 161 insertions(+), 141 deletions(-) > > Having scanned the discussion threads so far, I think the last four > patches are going against the list consensus of (1) it is OK to rely > on --git-completion-helper; using ancient Git with new completion > script won't obviously work, but that is "if it hurts, don't". (2) > some subcommands will fail the --git-completion-helper request > (e.g. outside a repository), but as long as the output from failed > request is not cached, it is OK. > > But we haven't seen any response to the earlier zsh specific > patches. Does it mean that nobody other than Felipe cares about > having a working Git completion for zsh? Or does it mean that all > users other than Felipe are happy with the current Git completion > for zsh and it works very well for them already? Or somewhere in > between? > > What I am trying to get at is if we would want to keep the earlier > zsh parts of the series, but with nobody seemingly interested in, it > is hard for me to justify queuing them. I'm not a Zsh user and am mostly unfamiliar with its antics, but FWIW... Zsh has its own git completion routines, which are in some aspects more advanced than what can be achieved with Bash's completion facilities (or more wasteful in screen real estate, depending on your preferences :), e.g. Zsh's completion shows a short description for each completeable --option and whatnot). I suppose that the avarage Zsh & Git user uses Zsh's own git completion instead of our Bash completion script wrapped for Zsh. Having said that, I applied the first 7 patches in my tree and then followed the updated installation instructions, and it finally worked. I remember trying it in the past once or twice, to check whether some of my bigger completion updates break something in Zsh, but it never worked. So these patches (and perhaps patch 10 as well) seem to be a definite improvement (though admittedly I haven't tested them thoroughly). As for the latter part of the series, I think the more hard-coded options we can get rid of the better we are off, and I would rather not see them making a comeback. I don't really have an opinion about patches 8 and 9 (that old wrapper is probably just bitrotting away, but I just tried to source our bash completion script from Zsh, and apart from the deprecation warning it appeared to work).
On Wed, Jul 3, 2019 at 12:50 PM Junio C Hamano <gitster@pobox.com> wrote: > But we haven't seen any response to the earlier zsh specific > patches. Does it mean that nobody other than Felipe cares about > having a working Git completion for zsh? Or does it mean that all > users other than Felipe are happy with the current Git completion > for zsh and it works very well for them already? Or somewhere in > between? The answer is obvious: the set of zsh users and the set of git developers don't overlap. > What I am trying to get at is if we would want to keep the earlier > zsh parts of the series, but with nobody seemingly interested in, it > is hard for me to justify queuing them. You are asking in the wrong forum. I would gladly point you to *dozens* of issues reported in Stack Overflow and Oh-My-Zsh if you don't believe me. Or you could just install zsh and see the issues for yourself.
On Wed, Jul 3, 2019 at 2:06 PM SZEDER Gábor <szeder.dev@gmail.com> wrote: > As for the latter part of the series, I think the more hard-coded > options we can get rid of the better we are off, and I would rather > not see them making a comeback. I don't really have an opinion about > patches 8 and 9 (that old wrapper is probably just bitrotting away, > but I just tried to source our bash completion script from Zsh, and > apart from the deprecation warning it appeared to work). I just added those patches to highlight the issue, which is very real, and you can see by running the added tests. I will maintain those patches separately in a branch named "hacks" in my project git-completion. If anybody wants the latest completion with an old version of Git they can use my project instead. https://github.com/felipec/git-completion/commits/hacks
Felipe Contreras <felipe.contreras@gmail.com> writes: >> What I am trying to get at is if we would want to keep the earlier >> zsh parts of the series, but with nobody seemingly interested in, it >> is hard for me to justify queuing them. > > You are asking in the wrong forum. > > I would gladly point you to *dozens* of issues reported in Stack > Overflow and Oh-My-Zsh if you don't believe me. Oh, no, there is no "believing" needed. Have you fed your patches to those folks who have dozens of issues and the patches made their life better? It does not help much to make me look at these forums; we need some way to make those in these forums aware of your improvements, try them out and report success, to help the wider range of users who are not even in these forums and struggling with their zsh-completion use (they will get their zsh/git completion from their distros---I am assuming that the distros get theirs from us in contrib/completion/). > Or you could just install zsh and see the issues for yourself. No, thanks. I am not a zsh user, and have no plan to become one ;-)
On Tue, Oct 27, 2020 at 2:23 PM Junio C Hamano <gitster@pobox.com> wrote: > > Felipe Contreras <felipe.contreras@gmail.com> writes: > > You are asking in the wrong forum. > > > > I would gladly point you to *dozens* of issues reported in Stack > > Overflow and Oh-My-Zsh if you don't believe me. > > Oh, no, there is no "believing" needed. > > Have you fed your patches to those folks who have dozens of issues > and the patches made their life better? Yes. > It does not help much to > make me look at these forums; we need some way to make those in > these forums aware of your improvements, try them out and report > success, They already are, and they already have. In those forums. > (they will get > their zsh/git completion from their distros---I am assuming that the > distros get theirs from us in contrib/completion/). I don't know of anyone that relies on the zsh completion shared by their distribution. > > Or you could just install zsh and see the issues for yourself. > > No, thanks. I am not a zsh user, and have no plan to become one ;-) You don't need to become a zsh user to test a patch. I often test bash completion patches on bash, even though I'm not a bash user. Cheers.
Felipe Contreras <felipe.contreras@gmail.com> writes: >> Have you fed your patches to those folks who have dozens of issues >> and the patches made their life better? > > Yes. That's good. >> (they will get >> their zsh/git completion from their distros---I am assuming that the >> distros get theirs from us in contrib/completion/). > > I don't know of anyone that relies on the zsh completion shared by > their distribution. Hmph. If the real users don't get the completion scripts from their distribution, is there still a point in having them in my tree? You are certainly not suggesting me to remove contrib/completion/ at least for zsh part, but then it is unclear what you want. Are you saying that by adding the latest and greatest, these real users who so far couldn't rely on distros now can start to do so, and we'll make their life easier by updating the 29-patch series (which I presume is the v2 of this 14-patch series)? In any case, some Zsh users, even though they are not active developers for the completion script, may have something good to say, now the 29-patch series has been posted to the list and queued. I didn't look at the zsh part, but I didn't find anything glaringly wrong in the changes to the bash completion. Thanks.
On Tue, Oct 27, 2020 at 5:32 PM Junio C Hamano <gitster@pobox.com> wrote: > > Felipe Contreras <felipe.contreras@gmail.com> writes: > >> (they will get > >> their zsh/git completion from their distros---I am assuming that the > >> distros get theirs from us in contrib/completion/). > > > > I don't know of anyone that relies on the zsh completion shared by > > their distribution. > > Hmph. If the real users don't get the completion scripts from their > distribution, is there still a point in having them in my tree? You > are certainly not suggesting me to remove contrib/completion/ at > least for zsh part, but then it is unclear what you want. I didn't say the users didn't get the scripts from the distribution, I said I didn't know of anyone that did. I just checked the installation instructions of Homebrew, and they do seem to install the zsh completion from contrib, whoever, by the time I see the bug reports, those users already downloaded the most recent version from GitHub [1]. On the other hand my distribution (Arch Linux) does not enable the zsh script by default, it just lies dormant in /usr/share/git/completion, which nobody uses. So users in Arch Linux naturally would download the latest version from GitHub [1] as well. So, which distributions package and enable the zsh script by default? Who knows. I suggested you to graduate those scripts out of contrib so distributions would trust the scripts enough to enable them by default, but you refused. What you do with the scripts is up to you, I only know what would happen depending on what you do. 1) If you leave them as is, some distributions would enable them, others don't, and people will keep downloading the scripts from git's GitHub [1]. 2) If you graduate them, more--if not all--distributions would enable them by default, and less people would download them. 3) If you remove them, people would look for another git repository to download those scripts from. > Are you saying that by adding the latest and greatest, these real > users who so far couldn't rely on distros now can start to do so, > and we'll make their life easier by updating the 29-patch series > (which I presume is the v2 of this 14-patch series)? No. Many of them will keep downloading the completion from git's mirror in GitHub [1]. Unless you graduate the scripts out of contrib. > In any case, some Zsh users, even though they are not active > developers for the completion script, may have something good to > say, now the 29-patch series has been posted to the list and queued. > I didn't look at the zsh part, but I didn't find anything glaringly > wrong in the changes to the bash completion. That's great. Although I have v3 already, since I found a couple of issues. I'll send those. Cheers. [1] https://github.com/git/git/blob/master/contrib/completion/git-completion.zsh
On 28.10.20 1:06, Felipe Contreras wrote: > On Tue, Oct 27, 2020 at 5:32 PM Junio C Hamano <gitster@pobox.com> wrote: >> >> Felipe Contreras <felipe.contreras@gmail.com> writes: > >>>> (they will get >>>> their zsh/git completion from their distros---I am assuming that the >>>> distros get theirs from us in contrib/completion/). >>> >>> I don't know of anyone that relies on the zsh completion shared by >>> their distribution. >> >> Hmph. If the real users don't get the completion scripts from their >> distribution, is there still a point in having them in my tree? You >> are certainly not suggesting me to remove contrib/completion/ at >> least for zsh part, but then it is unclear what you want. > > I didn't say the users didn't get the scripts from the distribution, I > said I didn't know of anyone that did. I just checked the installation > instructions of Homebrew, and they do seem to install the zsh > completion from contrib, whoever, by the time I see the bug reports, > those users already downloaded the most recent version from GitHub > [1]. I might not be the representative zsh user, but just as one data point: I have never downloaded the completion scripts from anywhere. I always use the one that comes with my "distro" (which is the Mac git installer, most of the time, which puts it in /usr/local/git/contrib/completion/). I symlink that to ~/.zfunc/_git. > On the other hand my distribution (Arch Linux) does not enable the zsh > script by default, it just lies dormant in /usr/share/git/completion, > which nobody uses. So users in Arch Linux naturally would download the > latest version from GitHub [1] as well. > > So, which distributions package and enable the zsh script by default? Who knows. > > I suggested you to graduate those scripts out of contrib so > distributions would trust the scripts enough to enable them by > default, but you refused. > > What you do with the scripts is up to you, I only know what would > happen depending on what you do. 1) If you leave them as is, some > distributions would enable them, others don't, and people will keep > downloading the scripts from git's GitHub [1]. 2) If you graduate > them, more--if not all--distributions would enable them by default, > and less people would download them. 3) If you remove them, people > would look for another git repository to download those scripts from. I don't think it makes a difference whether the scripts live in contrib or not. Bash completion is also in contrib, and yet it seems to be shipped and enabled by most distros, as far as I can tell. I guess the reason why zsh completion is not enabled by default in distros is simply that there are far fewer zsh users than bash users, so packagers don't bother. That's just my unfounded guess, of course. >> Are you saying that by adding the latest and greatest, these real >> users who so far couldn't rely on distros now can start to do so, >> and we'll make their life easier by updating the 29-patch series >> (which I presume is the v2 of this 14-patch series)? > > No. Many of them will keep downloading the completion from git's > mirror in GitHub [1]. > > Unless you graduate the scripts out of contrib. > >> In any case, some Zsh users, even though they are not active >> developers for the completion script, may have something good to >> say, now the 29-patch series has been posted to the list and queued. >> I didn't look at the zsh part, but I didn't find anything glaringly >> wrong in the changes to the bash completion. > > That's great. Although I have v3 already, since I found a couple of issues. > > I'll send those. > > Cheers. > > [1] https://github.com/git/git/blob/master/contrib/completion/git-completion.zsh >
On Wed, Oct 28, 2020 at 3:09 AM Stefan Haller <lists@haller-berlin.de> wrote: > > On 28.10.20 1:06, Felipe Contreras wrote: > > I didn't say the users didn't get the scripts from the distribution, I > > said I didn't know of anyone that did. I just checked the installation > > instructions of Homebrew, and they do seem to install the zsh > > completion from contrib, whoever, by the time I see the bug reports, > > those users already downloaded the most recent version from GitHub > > [1]. > > I might not be the representative zsh user, but just as one data point: > I have never downloaded the completion scripts from anywhere. I always > use the one that comes with my "distro" (which is the Mac git installer, > most of the time, which puts it in /usr/local/git/contrib/completion/). > I symlink that to ~/.zfunc/_git. That's interesting. Where did you get the idea to do that? > > On the other hand my distribution (Arch Linux) does not enable the zsh > > script by default, it just lies dormant in /usr/share/git/completion, > > which nobody uses. So users in Arch Linux naturally would download the > > latest version from GitHub [1] as well. > > > > So, which distributions package and enable the zsh script by default? Who knows. > > > > I suggested you to graduate those scripts out of contrib so > > distributions would trust the scripts enough to enable them by > > default, but you refused. > > > > What you do with the scripts is up to you, I only know what would > > happen depending on what you do. 1) If you leave them as is, some > > distributions would enable them, others don't, and people will keep > > downloading the scripts from git's GitHub [1]. 2) If you graduate > > them, more--if not all--distributions would enable them by default, > > and less people would download them. 3) If you remove them, people > > would look for another git repository to download those scripts from. > > I don't think it makes a difference whether the scripts live in contrib > or not. Bash completion is also in contrib, and yet it seems to be > shipped and enabled by most distros, as far as I can tell. Apples and oranges. There is no default completion for git in bash, neither in bash, nor in bash-completion, so if the distribution doesn't install the completion in the right place (/usr/share/bash-completion/completions/git), then the user would have no git completion. 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, 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. Cheers.
On 28.10.20 17:31, Felipe Contreras wrote: > On Wed, Oct 28, 2020 at 3:09 AM Stefan Haller <lists@haller-berlin.de> wrote: >> >> On 28.10.20 1:06, Felipe Contreras wrote: > >>> I didn't say the users didn't get the scripts from the distribution, I >>> said I didn't know of anyone that did. I just checked the installation >>> instructions of Homebrew, and they do seem to install the zsh >>> completion from contrib, whoever, by the time I see the bug reports, >>> those users already downloaded the most recent version from GitHub >>> [1]. >> >> I might not be the representative zsh user, but just as one data point: >> I have never downloaded the completion scripts from anywhere. I always >> use the one that comes with my "distro" (which is the Mac git installer, >> most of the time, which puts it in /usr/local/git/contrib/completion/). >> I symlink that to ~/.zfunc/_git. > > That's interesting. Where did you get the idea to do that? From the documentation in git-completion.zsh. I must have set this up at a time where the documentation was still correct (i.e. before it got broken in <https://github.com/gitster/git/commit/176f5adfdb01a>. -Stefan
Felipe Contreras <felipe.contreras@gmail.com> writes: > On Wed, Oct 28, 2020 at 3:09 AM Stefan Haller <lists@haller-berlin.de> wrote: >> >> I might not be the representative zsh user, but just as one data point: >> I have never downloaded the completion scripts from anywhere. I always >> use the one that comes with my "distro" (which is the Mac git installer, >> most of the time, which puts it in /usr/local/git/contrib/completion/). >> I symlink that to ~/.zfunc/_git. That's one data point. >> I don't think it makes a difference whether the scripts live in contrib >> or not. Bash completion is also in contrib, and yet it seems to be >> shipped and enabled by most distros, as far as I can tell. > > Apples and oranges. > > There is no default completion for git in bash, neither in bash, nor > in bash-completion, so if the distribution doesn't install the > completion in the right place > (/usr/share/bash-completion/completions/git), then the user would have > no git completion. True, as far as I know. https://github.com/scop/bash-completion does not seem to have an entry for "git" (/usr/share/bash-completion/completions/git however is locally there on my box---probably the corp IT folks installed it there), so what we ship in contrib/ is the most used (if not the only) implementation of bash completion script. > 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)? Stefan? If at least some people argue what comes with zsh by default is more complete than the one we have in contrib/, what led you choose to "symlink" the less complete one to use it instead? Another question (this is for Felipe). Is https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/gitfast the one that comes with zsh by default, or is it something else (perhaps it is the go-to version for those who are not satisfied with the version that comes with zsh by default???)? Thanks.
Junio C Hamano <gitster@pobox.com> writes: > Felipe Contreras <felipe.contreras@gmail.com> 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/ - https://stackoverflow.com/questions/24513873/ which was near the top had these gems. https://stackoverflow.com/a/58517668 Actually, ZSH does know how to do git completion out of the box, but you need to turn on the completion feature itself (which from the steps you described I guess you haven't done) and https://stackoverflow.com/a/63894520 Turns out the problem for me wass that when installing git via homebrew, git installs its own zsh shell extension which is considerably less complete/capable than the default that oh-my-szh installs. Find out what versions your git install is and then remove the zsh autocompletions. Mine were here and deleted thusly: rm -rf /usr/local/Cellar/git/2.28.0/share/zsh/ The "knows out of the box" in https://stackoverflow.com/a/58517668 is matches your "zsh by default has". > 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". 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. A good zsh autocompletion would need to be written and reviewed by those who know zsh completion well. They also need to know Git somewhat, but the expertise on the former would be a lot more important, I would think. But as you said in <CAMP44s3wqxTmgQpMgk2cM33EvtwrvvXYv4_90GKGmHb8yJHAKg@mail.gmail.com> 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. 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. We may also want to have a tombstone in contrib/completion/ to redirect the users to the default version and away from our "less complete/capable" one. Thanks.
On 29.10.20 18:16, Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > >> On Wed, Oct 28, 2020 at 3:09 AM Stefan Haller <lists@haller-berlin.de> wrote: >>> >>> I might not be the representative zsh user, but just as one data point: >>> I have never downloaded the completion scripts from anywhere. I always >>> use the one that comes with my "distro" (which is the Mac git installer, >>> most of the time, which puts it in /usr/local/git/contrib/completion/). >>> I symlink that to ~/.zfunc/_git. > > That's one data point. > >>> I don't think it makes a difference whether the scripts live in contrib >>> or not. Bash completion is also in contrib, and yet it seems to be >>> shipped and enabled by most distros, as far as I can tell. >> >> Apples and oranges. >> >> There is no default completion for git in bash, neither in bash, nor >> in bash-completion, so if the distribution doesn't install the >> completion in the right place >> (/usr/share/bash-completion/completions/git), then the user would have >> no git completion. > > True, as far as I know. https://github.com/scop/bash-completion does not > seem to have an entry for "git" (/usr/share/bash-completion/completions/git > however is locally there on my box---probably the corp IT folks installed > it there), so what we ship in contrib/ is the most used (if not the only) > implementation of bash completion script. > >> 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)? It's the same on Mac; I get zsh's builtin git completion when I don't install ours. > Stefan? If at least some people argue what comes with zsh by > default is more complete than the one we have in contrib/, what led > you choose to "symlink" the less complete one to use it instead? I'm not sure I can answer the question which one is more complete. Ours is certainly complete enough for my daily use, but this might not mean much. The reason why I chose ours over the one that comes with zsh is that ours is *way* faster. If I type "git log origin/mas<tab>", with zsh's completion it takes between one and two seconds to auto-complete this to "origin/master". With ours it's instantaneous. > Another question (this is for Felipe). Is > > https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/gitfast > > the one that comes with zsh by default, or is it something else > (perhaps it is the go-to version for those who are not satisfied > with the version that comes with zsh by default???)? > > Thanks. >
Stefan Haller <lists@haller-berlin.de> writes: >> How is that completion script developed, maintained and distributed? I think we should ask this question to those in Zsh development community. >> 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)? > > It's the same on Mac; I get zsh's builtin git completion when I don't > install ours. I see. That makes sense. >> Stefan? If at least some people argue what comes with zsh by >> default is more complete than the one we have in contrib/, what led >> you choose to "symlink" the less complete one to use it instead? > > I'm not sure I can answer the question which one is more complete. Ours > is certainly complete enough for my daily use, but this might not mean much. > > The reason why I chose ours over the one that comes with zsh is that > ours is *way* faster. If I type "git log origin/mas<tab>", with zsh's > completion it takes between one and two seconds to auto-complete this to > "origin/master". With ours it's instantaneous. That is a very good data point. I re-read the blurb on the "gitfast" thing (below) in ohmyzsh and learned that ... >> Another question (this is for Felipe). Is >> >> https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/gitfast >> >> the one that comes with zsh by default, or is it something else >> (perhaps it is the go-to version for those who are not satisfied >> with the version that comes with zsh by default???)? ... it repackages what we have in contrib/ and promises a faster completion (which aligns with the reason you stated why you chose ours) than the Zsh default one and being always fresh (by frequent updates from our contrib/). In other words, my understanding is that it is positioned as a competitor to the Zsh default. After making a brief observation for my previous message in the thread, I understand that oh-my-zsh is a very popular colleciton of third-party stuff for Zsh users, so it seems to me that the real useful choices, if I or somebody else were to become a new Zsh user, are between sticking with the Zsh default or grabbing the improved version from oh-my-zsh collection. I could also use from our contrib/ but I would have to ask myself twice why should I, as a (hypothetical) new Zsh user, bother, especially when the latter promises to be always fresh anyway. Thanks.
On Thu, Oct 29, 2020 at 11:16 AM Junio C Hamano <gitster@pobox.com> wrote: > Felipe Contreras <felipe.contreras@gmail.com> 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 the maintainers of Zsh. > 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)? I don't believe it's different. > Another question (this is for Felipe). Is > > https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/gitfast > > the one that comes with zsh by default, or is it something else > (perhaps it is the go-to version for those who are not satisfied > with the version that comes with zsh by default???)? It's for the people who are not satisfied with the default Zsh version, which are a lot.
On Thu, Oct 29, 2020 at 11:27 AM Junio C Hamano <gitster@pobox.com> wrote: > > Junio C Hamano <gitster@pobox.com> writes: > > > Felipe Contreras <felipe.contreras@gmail.com> 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@mail.gmail.com> > > 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
On Fri, Oct 30, 2020 at 11:19 AM Junio C Hamano <gitster@pobox.com> wrote: > After making a brief observation for my previous message in the > thread, I understand that oh-my-zsh is a very popular colleciton of > third-party stuff for Zsh users, so it seems to me that the real > useful choices, if I or somebody else were to become a new Zsh user, > are between sticking with the Zsh default or grabbing the improved > version from oh-my-zsh collection. I could also use from our > contrib/ but I would have to ask myself twice why should I, as a > (hypothetical) new Zsh user, bother, especially when the latter > promises to be always fresh anyway. More or less. Oh-My-Zsh is very popular, but not everyone uses it, and it's certainly not cheap on resources (it makes the startup a bit slower). So the two options are: 1. Use the script in contrib/ (or git-completion) 2. Use Oh-My-Zsh and enable the "gitfast" plugin In my opinion to use the Zsh default completion is not an option. Which is why I think distributions should package the Git Zsh completion by default (like Hombrew does), which will happen more easily if Git graduated those scripts and installed them by default. If this close-to-ideal solution was considered, I would investigate again if there's a way to automate the testing of the Zsh wrapper, so that it doesn't break when the Bash script is updated (which is the usual way the Zsh wrapper breaks). Cheers.
At 14:29 -0600 02 Nov 2020, Felipe Contreras <felipe.contreras@gmail.com> wrote: >So the two options are: > >1. Use the script in contrib/ (or git-completion) >2. Use Oh-My-Zsh and enable the "gitfast" plugin > >In my opinion to use the Zsh default completion is not an option. > >Which is why I think distributions should package the Git Zsh >completion by default (like Hombrew does), which will happen more >easily if Git graduated those scripts and installed them by default. The option that you consider to be invalid is definitely *my* preferred option. That Homebrew's git package installs the completion in a way that overrides that from the zsh package was a source of continual annoyance for me until I put in a long-term workaround for that (I had just been removing the symlink every time I noticed that it had been created by a new install of the git package). While the completion provided by git.git may be faster, the one from zsh is fast enough on the repositories that I generally work with. At least with my configuration and the completion code currently shipped by Homobrew's git package there are at least a couple of things that seem to be quite broken. The one that generally caused me to notice that the wrong completion code was being used is that it doesn't provide completion for creating local branches to based off of remote ones; I'd previously thought that was just a missing feature, but looking into it a bit more now it looks like that **should** happen as long as I don't set GIT_COMPLETION_CHECKOUT_NO_GUESS=1. The other thing that seems to not work with the completion from git.git is completion of single-dash options. Although that may be more of a missing feature rather than something that's broken. Since there isn't any description for long options, I'd guess there wouldn't be for short options either; in which case there isn't really any point to trying to offer completion for those. But, having additional descriptions for options is one of my favorite features of zsh completion.
Aaron Schrab <aaron@schrab.com> writes: > At 14:29 -0600 02 Nov 2020, Felipe Contreras <felipe.contreras@gmail.com> wrote: >>So the two options are: >> >>1. Use the script in contrib/ (or git-completion) >>2. Use Oh-My-Zsh and enable the "gitfast" plugin >> >>In my opinion to use the Zsh default completion is not an option. >> >>Which is why I think distributions should package the Git Zsh >>completion by default (like Hombrew does), which will happen more >>easily if Git graduated those scripts and installed them by default. > > The option that you consider to be invalid is definitely *my* > preferred option. That Homebrew's git package installs the completion > in a way that overrides that from the zsh package was a source of > continual annoyance for me until I put in a long-term workaround for > that (I had just been removing the symlink every time I noticed that > it had been created by a new install of the git package). Thanks for a data point. My understanding is that Felipe's 1 & 2 are essentially the same thing in the larger picture but they come in different packaging. If we talk about two choices, I think they are between the Zsh default or gitfast from oh-my-zsh. And your preference is the former. It is not like I picked a wrong SO thread and was swayed by an oddball opinion of somebody who prefers the Zsh default. Even though the preference is up to individual users, the important point here is that Zsh default is not universally unusable for everybody and it is one of the valid choices.
Felipe Contreras <felipe.contreras@gmail.com> writes: >> 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. Do you mean by "the wrapper" the 'gitfast' one you offer in the oh-my-zsh collection? If so, yes, I agree that 'gitfast' as "maybe less complete but usably faster auto-completer" is a good thing for end-users to have as an alternative to the Zsh default. But that was not the point I was raising. I was saying that it was not making life better for them that we are posing as a valid third choice in that competition. Your "wrapper" can still be updated regularly to the latest to grab the bash completion part from "git.git". To the Zsh audience, however, it would be more straight-forward if the choices were "there is Zsh default completion, but if you want to use a different/better version, grab 'gitfast' from the oh-my-zsh collection" than "you can use Zsh default, or you can install 'gitfast' in the way Zsh users are accustomed to from the oh-my-zsh collection, or you can manually install from git.git". After all, the latter two would give them the same thing. It may be a good idea to leave a message in contrib/completion that nudges people toward 'gitfast' as an alternative for thowe who want to use something other than the default Zsh autocompletion. Doing so would remove one level of unnecessary middleman (that is us) from the picture and make it simpler for end-users by reducing the number of choices from three to two. > They prioritize completeness over usability. > ... > No. Those people don't care if their completion is unusable. > ... > This is not possible, as the Zsh maintainers don't care about usability. I think our code of conduct applies to derogatory statements made on even those who do not regularly appear in this community. If you want to attack them, please don't do it here. Thanks.
On 30.10.20 18:19, Junio C Hamano wrote: > Stefan Haller <lists@haller-berlin.de> writes: > >>> How is that completion script developed, maintained and distributed? > > I think we should ask this question to those in Zsh development > community. > >>> 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)? >> >> It's the same on Mac; I get zsh's builtin git completion when I don't >> install ours. > > I see. That makes sense. > >>> Stefan? If at least some people argue what comes with zsh by >>> default is more complete than the one we have in contrib/, what led >>> you choose to "symlink" the less complete one to use it instead? >> >> I'm not sure I can answer the question which one is more complete. Ours >> is certainly complete enough for my daily use, but this might not mean much. >> >> The reason why I chose ours over the one that comes with zsh is that >> ours is *way* faster. If I type "git log origin/mas<tab>", with zsh's >> completion it takes between one and two seconds to auto-complete this to >> "origin/master". With ours it's instantaneous. > > That is a very good data point. I re-read the blurb on the > "gitfast" thing (below) in ohmyzsh and learned that ... > >>> Another question (this is for Felipe). Is >>> >>> https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/gitfast >>> >>> the one that comes with zsh by default, or is it something else >>> (perhaps it is the go-to version for those who are not satisfied >>> with the version that comes with zsh by default???)? > > ... it repackages what we have in contrib/ and promises a faster > completion (which aligns with the reason you stated why you chose > ours) than the Zsh default one and being always fresh (by frequent > updates from our contrib/). In other words, my understanding is > that it is positioned as a competitor to the Zsh default. > > After making a brief observation for my previous message in the > thread, I understand that oh-my-zsh is a very popular colleciton of > third-party stuff for Zsh users, so it seems to me that the real > useful choices, if I or somebody else were to become a new Zsh user, > are between sticking with the Zsh default or grabbing the improved > version from oh-my-zsh collection. I could also use from our > contrib/ but I would have to ask myself twice why should I, as a > (hypothetical) new Zsh user, bother, especially when the latter > promises to be always fresh anyway. Using stuff from oh-my-zsh is not an option for me. I'm not using oh-my-zsh, and I don't want to begin using it just for this one package. I could use Felipe's version from <https://github.com/felipec/git-completion> (and in fact, that's what I'm doing right now, for testing. Works great. :-) However, I'd have to remember to manually update it every so often. So yes, I prefer to use the one from git's distribution, because it is automatically kept up to date whenever I update git (as long as I symlink to it rather than copy it.) -Stefan
Stefan Haller <lists@haller-berlin.de> writes: > Using stuff from oh-my-zsh is not an option for me. I'm not using > oh-my-zsh, and I don't want to begin using it just for this one package. > > I could use Felipe's version from > <https://github.com/felipec/git-completion> (and in fact, that's what > I'm doing right now, for testing. Works great. :-) However, I'd have to > remember to manually update it every so often. > > So yes, I prefer to use the one from git's distribution, because it is > automatically kept up to date whenever I update git (as long as I > symlink to it rather than copy it.) Thanks for another data point. You'd need to add to another "as long as", which is "as long as it keeps up with felipec/git-completion". If we fall bahind, you'd be better off getting updates directly from there, not from us. And I suspect that not many Zsh users want to care about the distinction between the two. If it were as easy to grab the latest version of Felipe's as an update of Git from your distro, wouldn't most people rather choose to do so? If we are not doing much reviews on Zsh completion on this list, due to lack of interest and expertise, then we will either fall behind, or blindly copy, Felipe's repository and republish as a small part of our project, without adding much value ourselves. Which is not a very happy place for us to be in. I dunno.
On 03.11.20 18:12, Junio C Hamano wrote: > Stefan Haller <lists@haller-berlin.de> writes: > >> Using stuff from oh-my-zsh is not an option for me. I'm not using >> oh-my-zsh, and I don't want to begin using it just for this one package. >> >> I could use Felipe's version from >> <https://github.com/felipec/git-completion> (and in fact, that's what >> I'm doing right now, for testing. Works great. :-) However, I'd have to >> remember to manually update it every so often. >> >> So yes, I prefer to use the one from git's distribution, because it is >> automatically kept up to date whenever I update git (as long as I >> symlink to it rather than copy it.) > > Thanks for another data point. > > You'd need to add to another "as long as", which is "as long as it > keeps up with felipec/git-completion". If we fall bahind, you'd be > better off getting updates directly from there, not from us. Yes, that's true of course. That's why I'm happy that Felipe contributes his version here, and that you are accepting it quickly. > And I suspect that not many Zsh users want to care about the > distinction between the two. If it were as easy to grab the latest > version of Felipe's as an update of Git from your distro, wouldn't > most people rather choose to do so? > > If we are not doing much reviews on Zsh completion on this list, due > to lack of interest and expertise, then we will either fall behind, > or blindly copy, Felipe's repository and republish as a small part > of our project, without adding much value ourselves. > > Which is not a very happy place for us to be in. I dunno. I still think it's valuable to do this. And I think the fact that it's in contrib makes it less likely that we fall behind, because you can just choose to merge updates without very thorough reviews (like with the current patch series), which you probably wouldn't feel comfortable doing if it had "graduated" out of contrib, as Felipe requests. -Stefan
On Mon, Nov 2, 2020 at 5:05 PM Aaron Schrab <aaron@schrab.com> wrote: > The option that you consider to be invalid is definitely *my* preferred > option. That Homebrew's git package installs the completion in a way > that overrides that from the zsh package was a source of continual > annoyance for me until I put in a long-term workaround for that (I had > just been removing the symlink every time I noticed that it had been > created by a new install of the git package). You are probably a minority. Just put the location of your desired completion in front of your fpath fpath=(/usr/share/zsh/functions/Completion/Unix $fpath) > While the completion provided by git.git may be faster, the one from zsh > is fast enough on the repositories that I generally work with. There's no such thing as "fast enough" for most Git developers. > At least > with my configuration and the completion code currently shipped by > Homobrew's git package there are at least a couple of things that seem > to be quite broken. If they are still broken in this version: https://github.com/felipec/git-completion Feel free to open an issue report. > The one that generally caused me to notice that the wrong completion > code was being used is that it doesn't provide completion for creating > local branches to based off of remote ones; I'd previously thought that > was just a missing feature, but looking into it a bit more now it looks > like that **should** happen as long as I don't set > GIT_COMPLETION_CHECKOUT_NO_GUESS=1. That was a bug because somebody added a new function to the Bash script and forgot to add it to the Zsh script. I've sent the fix: https://lore.kernel.org/git/20201028020712.442623-14-felipe.contreras@gmail.com/ > The other thing that seems to not work with the completion from git.git > is completion of single-dash options. Although that may be more of a > missing feature rather than something that's broken. Since there isn't > any description for long options, I'd guess there wouldn't be for short > options either; in which case there isn't really any point to trying to > offer completion for those. But, having additional descriptions for > options is one of my favorite features of zsh completion. That's a feature request. It may work at some point, but it would require a lot of work. In the meantime you can simply use the default Zsh completion. The point of the Zsh completion is to offer everything the Bash completion offers. Which is clearly fine for most people, since that's the completion most people use. Cheers.
On Mon, Nov 2, 2020 at 7:35 PM Junio C Hamano <gitster@pobox.com> wrote: > My understanding is that Felipe's 1 & 2 are essentially the same > thing in the larger picture but they come in different packaging. Yes, and no. That's like saying you get the same thing with Gentoo than with Ubuntu. Yes; you get the same thing, but no; Oh-My-Zsh comes with a lot more you might not necessarily want. > And your preference is the former. It is not like I picked a wrong > SO thread and was swayed by an oddball opinion of somebody who > prefers the Zsh default. Even though the preference is up to > individual users, the important point here is that Zsh default is > not universally unusable for everybody and it is one of the valid > choices. I think that's debatable. If I had to be it would be on a 50/50 split. But that's considering that most people never change their default. If my script were the default, my bet would be on a 90/10 split (at least). Yes, there are some people who do prefer the Zsh default but not many. Seriously, submit yourself to one hour of the default Zsh completion, I bet you will consider it torture.
On Mon, Nov 2, 2020 at 7:49 PM Junio C Hamano <gitster@pobox.com> wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > > There's a reason people prefer to use Git's official completion, and > > there's a reason I wrote the wrapper. > > Do you mean by "the wrapper" the 'gitfast' one you offer in the > oh-my-zsh collection? If so, yes, I agree that 'gitfast' as "maybe > less complete but usably faster auto-completer" is a good thing for > end-users to have as an alternative to the Zsh default. No, I mean the Git Zsh wrapper that I wrote. It's in three locations right now: 1. https://git.kernel.org/pub/scm/git/git.git/tree/contrib/completion/git-completion.zsh 2. https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/gitfast/_git 3. https://github.com/felipec/git-completion/blob/master/git-completion.zsh All these are the same thing. If git was installing this wrapper by default, there would be no need for the gitfast plugin, nor the git-completion project. > But that was not the point I was raising. I was saying that it was > not making life better for them that we are posing as a valid third > choice in that competition. > > Your "wrapper" can still be updated regularly to the latest to grab > the bash completion part from "git.git". To the Zsh audience, > however, it would be more straight-forward if the choices were > "there is Zsh default completion, but if you want to use a > different/better version, grab 'gitfast' from the oh-my-zsh > collection" than "you can use Zsh default, or you can install > 'gitfast' in the way Zsh users are accustomed to from the oh-my-zsh > collection, or you can manually install from git.git". After all, > the latter two would give them the same thing. The default is by definition not a choice. You make a choice to move away from the default. And the gitfast plugin is not different from what was in contrib, in fact I wrote a script to update it directly from there [1] (I changed it recently to fetch from the git-completion project). > It may be a good idea to leave a message in contrib/completion that > nudges people toward 'gitfast' as an alternative for thowe who want > to use something other than the default Zsh autocompletion. If we are going to leave a message it would have to be for git-completion, since not all zsh users use Oh-MyZsh (maybe most don't), and gitfast is nothing but a copy of git-completion. > Doing so would remove one level of unnecessary middleman (that is > us) from the picture and make it simpler for end-users by reducing > the number of choices from three to two. This would break the experience of Homebrew users, and possibly Linux distributions that do package this wrapper by default. But if you are not going to consider graduating the scripts, we might as well break the experience for everyone, so everyone is at the same level. > > They prioritize completeness over usability. > > ... > > No. Those people don't care if their completion is unusable. > > ... > > This is not possible, as the Zsh maintainers don't care about usability. > > I think our code of conduct applies to derogatory statements made on > even those who do not regularly appear in this community. To state the opinion of a person is not a derogatory statement. This is literally what they said: > > > Now, how about you make a compromise between "correctness" and > > > usability? > > > > No. I'm not doing anything but repeating their stated opinion. It is a fact. If you don't like their stated opinion, feel free to talk to them. Cheers. [1] https://github.com/ohmyzsh/ohmyzsh/blob/d69bad8eb4157e5fd5c1a4ce98f93cf522477a8c/plugins/gitfast/update
Felipe Contreras <felipe.contreras@gmail.com> writes: > To state the opinion of a person is not a derogatory statement. This > is literally what they said: > >> > > Now, how about you make a compromise between "correctness" and >> > > usability? >> > >> > No. > > I'm not doing anything but repeating their stated opinion. It is a > fact. If you don't like their stated opinion, feel free to talk to > them. I had to read the exchange three times to be reasonably confident that the party that was asking the question was you and Zsh folks was who said "No.", as there were so little in the context to go by, in order to tell what was being discussed (I initially even thought they asked the question and you gave a short "no", before realizing it probably is the other way around). In the short quote given without enough context, I cannot see anything more than a disagreement of the degree of "correctness" and "usability" expected by the two parties in the discussion. Even if I knew what exact "incorrectness" and "usability" were on topic back when you two argued, I know people strike balance at different place. Even though I may agree with your argument in that particular case, I can understand (if not accept) if Zsh folks thought differently. And it does not matter if I agree with you that they are better off taking a small "incorrectness" to gain "usability"---the Zsh show is run over there by Zsh folks, and I am not a participant. But the take-away I got from your short quote was that I see no evidence that Zsh folks do not care about usability.
On Wed, Nov 4, 2020 at 12:08 PM Junio C Hamano <gitster@pobox.com> wrote: > But the take-away I got from your short quote was that I see no > evidence that Zsh folks do not care about usability. This exchange happened 9 years ago, so I wouldn't place too much of a burden on what they actually meant by what they said. Even if my interpretation of what they said at that point of time is 100% incorrect; it's not a *derogatory* statement; it would simply be an unfactual statement. I will contact them again with some fixes to their code, but not just yet. Cheers.
Felipe Contreras <felipe.contreras@gmail.com> writes: > On Wed, Nov 4, 2020 at 12:08 PM Junio C Hamano <gitster@pobox.com> wrote: > >> But the take-away I got from your short quote was that I see no >> evidence that Zsh folks do not care about usability. > > This exchange happened 9 years ago, so I wouldn't place too much of a > burden on what they actually meant by what they said. In other words, you are now saying that it does not demonstrate your earlier claim that they do not care about usability at all? > Even if my interpretation of what they said at that point of time is > 100% incorrect; it's not a *derogatory* statement; it would simply be > an unfactual statement. So, the short quote given without much context was an attempt to mislead those who are reading this discussion? That sounds even worse to me. In any case, so far you managed to convince me even less that it would help the Zsh userbase to carry a "by default has to fall behind" copy of what they can get, or their distro packagers can package, the latest and greatest directly from your github repository as part of the release of this project. Thanks, and bye for now.