* Strange behavior about option completion of `git push`
@ 2020-09-17 17:22 Yasuhiro KIMURA
2020-09-17 18:05 ` Bart Schaefer
2020-09-17 19:36 ` Oliver Kiddle
0 siblings, 2 replies; 4+ messages in thread
From: Yasuhiro KIMURA @ 2020-09-17 17:22 UTC (permalink / raw)
To: zsh-users
Hello,
I use zsh 5.8 on some OSes (CentOS, Cygwin, Debian, FreeBSD, etc.) and
found strange behavior about option completion of `git push`.
At first let's type `git push --r` and hit TAB. Then it is completed
as `git push --re`. Options of `git push` that start with `--r` are
`--receive-pack`, `--recurse-submodules` and `--repo` and all of them
start with `--re`. So it is reasonable that completion works as above.
Next let's type `git push --f' and hit TAB. In this case options that
start with `--f' are `--follow-tags`, `--force` and
`--force-with-lease` and all of them start with `--fo`. So expected
behavior is that it will be completed as `git push --fo`. But what
really happens is that there is no change after TAB is hit.
I checked definition of `_git-push` function in
/usr/share/zsh/5.8/functions/Completion/Unix/_git but didn't find the
source of the difference.
Would someone please explain why such differnce happens?
Best Regards.
---
Yasuhiro KIMURA
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Strange behavior about option completion of `git push`
2020-09-17 17:22 Strange behavior about option completion of `git push` Yasuhiro KIMURA
@ 2020-09-17 18:05 ` Bart Schaefer
2020-09-17 19:36 ` Oliver Kiddle
1 sibling, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2020-09-17 18:05 UTC (permalink / raw)
To: Yasuhiro KIMURA; +Cc: Zsh Users
On Thu, Sep 17, 2020 at 10:24 AM Yasuhiro KIMURA <yasu@utahime.org> wrote:
>
> At first let's type `git push --r` and hit TAB. Then it is completed
> as `git push --re`.
>
> Next let's type `git push --f' and hit TAB. In this case ... expected
> behavior is that it will be completed as `git push --fo`. But what
> really happens is that there is no change after TAB is hit.
>
> Would someone please explain why such differnce happens?
I think the difference is that --force-with-lease has a required
argument, which differs from the other two --f options, whereas none
of the --r completions has an argument.
However, without a lot of digging, I don't know why that affects the
position of the first perceived ambiguity.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Strange behavior about option completion of `git push`
2020-09-17 17:22 Strange behavior about option completion of `git push` Yasuhiro KIMURA
2020-09-17 18:05 ` Bart Schaefer
@ 2020-09-17 19:36 ` Oliver Kiddle
2020-09-18 3:11 ` Yasuhiro KIMURA
1 sibling, 1 reply; 4+ messages in thread
From: Oliver Kiddle @ 2020-09-17 19:36 UTC (permalink / raw)
To: Yasuhiro KIMURA; +Cc: zsh-users
Yasuhiro KIMURA wrote:
> Next let's type `git push --f' and hit TAB. In this case options that
> start with `--f' are `--follow-tags`, `--force` and
> `--force-with-lease` and all of them start with `--fo`. So expected
> behavior is that it will be completed as `git push --fo`. But what
> really happens is that there is no change after TAB is hit.
This appears to be a bug in the zsh completion internals. The difference
between --f and --r is that for --f, the options are added with more
than one call to compadd because there's a mix of suffix characters
required on those options.
Any further discussion on this line should probably go to -workers but a
minimal function to reproduce the issue is as follows:
compadd -M 'r:|.=*' one
compadd -M 'r:|-=*' - --follow-tags --force
compadd -M 'r:|-=*' - --force-with-lease
return 0
With _git_push the first of these compadd calls is from _ssh_hosts. The
matching control options are needed. The latter two with - as a pivot
but the first can use any character. The case with --r is equivalent to
combining the latter two compadd calls into a single call.
Matching control is known to have some gnarly issues.
Oliver
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Strange behavior about option completion of `git push`
2020-09-17 19:36 ` Oliver Kiddle
@ 2020-09-18 3:11 ` Yasuhiro KIMURA
0 siblings, 0 replies; 4+ messages in thread
From: Yasuhiro KIMURA @ 2020-09-18 3:11 UTC (permalink / raw)
To: zsh-users
From: Bart Schaefer <schaefer@brasslantern.com>
Subject: Re: Strange behavior about option completion of `git push`
Date: Thu, 17 Sep 2020 11:05:43 -0700
> I think the difference is that --force-with-lease has a required
> argument, which differs from the other two --f options, whereas none
> of the --r completions has an argument.
Oh, I didn't notice it.
From: Oliver Kiddle <opk@zsh.org>
Subject: Re: Strange behavior about option completion of `git push`
Date: Thu, 17 Sep 2020 21:36:19 +0200
> This appears to be a bug in the zsh completion internals. The difference
> between --f and --r is that for --f, the options are added with more
> than one call to compadd because there's a mix of suffix characters
> required on those options.
>
> Any further discussion on this line should probably go to -workers but a
> minimal function to reproduce the issue is as follows:
>
> compadd -M 'r:|.=*' one
> compadd -M 'r:|-=*' - --follow-tags --force
> compadd -M 'r:|-=*' - --force-with-lease
> return 0
>
> With _git_push the first of these compadd calls is from _ssh_hosts. The
> matching control options are needed. The latter two with - as a pivot
> but the first can use any character. The case with --r is equivalent to
> combining the latter two compadd calls into a single call.
>
> Matching control is known to have some gnarly issues.
It seems too much for me to handle this issue. So I would like to
leave the investigation of it to someone familiar with the internals
of zsh completion.
---
Yasuhiro KIMURA
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-18 3:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-17 17:22 Strange behavior about option completion of `git push` Yasuhiro KIMURA
2020-09-17 18:05 ` Bart Schaefer
2020-09-17 19:36 ` Oliver Kiddle
2020-09-18 3:11 ` Yasuhiro KIMURA
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).