zsh-users
 help / color / mirror / Atom feed
* 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

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git