characters not added in _rsync completion

characters not added in _rsync completion

[Wayne Davison]

I've noticed something strange in the _rsync completion in 4.2.1 (I
tested both the debian packaged version of 4.2.1 and the latest CVS):
zsh sometimes fails to add all the common characters that it should
when completing an ambiguous option.  For example:

zsh -f
autoload -U compinit
compinit
rsync --bl<TAB>

The characters "ock" should be added (since the "--block" prefix is
common to both the listed completions), but nothing is added (the user
must either type more characters to remove the ambiguity, or cycle
through the matches with more TAB presses).

Other completions that fail to add common characters:

rsync --ch<TAB>    # should add "ecksum"
rsync --com<TAB>   # should add "p"
rsync --li<TAB>    # should add "nk"
rsync --no<TAB>    # should add "-"
rsync --par<TAB>   # should add "tial"
rsync --ti<TAB>    # should add "me"

(Note that two of those require a very recent rsync that has the
--checksum-seed and --partial-dir options, otherwise there would
be only one option to complete.)

However, most other options behave in the expected manner:

rsync --ba<TAB>    # adds "ckup"
rsync --del<TAB>   # adds "ete"
rsync --exc<TAB>   # adds "lude"
rsync --ig<TAB>    # adds "nore-"
rsync --inc<TAB>   # adds "lude"
rsync --v<TAB>     # adds "er"

Would anyone care to look into this?

..wayne..

Re: characters not added in _rsync completion

[Bart Schaefer]

On Tue, 12 Oct 2004, Wayne Davison wrote:

> zsh sometimes fails to add all the common characters that it should
> when completing an ambiguous option.
[...]
> (Note that two of those require a very recent rsync that has the
> --checksum-seed and --partial-dir options, otherwise there would
> be only one option to complete.)

I'm puzzled why the version of rsync itself makes any difference, because 
_rsync specifies everything explicitly, so unless you've edited _rsync it 
won't ever complete those options.  Does Debian come with an updated 
_rsync for which a patch has not been posted back to zsh-workers?

Similarly, I have only --links and nothing else that matches --link.
However, I can reproduce this for several of the others that you list:

> rsync --com<TAB>   # should add "p"
> rsync --par<TAB>   # should add "tial"
> rsync --ti<TAB>    # should add "me"

Yet this one works for me:

> rsync --no<TAB>    # should add "-"

(That is, I do get "-" added when completing there.)

> Would anyone care to look into this?

Without plunging into the why of it, a cursory inspection seems to 
indicate that when an option has an argument (e.g., --compa completes to 
--compare-dest= with the trailing equal sign) then zsh fails to find the 
longest common prefix among that option and any other options that do NOT 
have arguments (as --compress does not).  All the cases that fail appear 
to have at least one option with, and at least one without, an argument.

Re: characters not added in _rsync completion

[Clint Adams]

> won't ever complete those options.  Does Debian come with an updated 
> _rsync for which a patch has not been posted back to zsh-workers?

No, it's the stock 4.2.1 _rsync.

Re: characters not added in _rsync completion

[Wayne Davison]

On Tue, Oct 12, 2004 at 11:41:52PM -0700, Bart Schaefer wrote:
> I'm puzzled why the version of rsync itself makes any difference,
> because _rsync specifies everything explicitly, so unless you've
> edited _rsync it won't ever complete those options.

This is not how it works on my system.  The _rsync script appears to be
querying rsync to ask it what options it supports, and combining that
list with the list in _rsync.  So, if, for instance, you've installed
the rsync 2.6.3 package from debian unstable, the new options from all
the 2.6.x versions get listed, just without descriptions.

> Similarly, I have only --links and nothing else that matches --link.

Earlier rsyncs (prior to 2.6.0) didn't list --link-dest in their help
text, even when the option was supported (and our _rsync script was
missing this option as well -- I've fixed that in the latest CVS
version).

> Yet this one works for me:
> > rsync --no<TAB>    # should add "-"

If I change rsync to 2.5.7 on my system, that one also begins to work.
However, with either a newer rsync (which lists --no-relative and
--no-implied-dirs in the help output) or if you edit the --no-relative
option into the _rsync script, it begins to fail.

> Without plunging into the why of it, a cursory inspection seems to 
> indicate that when an option has an argument (e.g., --compa completes to 
> --compare-dest= with the trailing equal sign) then zsh fails to find the 
> longest common prefix among that option and any other options that do NOT 
> have arguments (as --compress does not).  All the cases that fail appear 
> to have at least one option with, and at least one without, an argument.

It's strange that the --no<TAB> case doesn't match this idea.

..wayne..

Re: characters not added in _rsync completion

[Wayne Davison]

On Wed, Oct 13, 2004 at 09:46:26AM -0700, Wayne Davison wrote:
> The _rsync script appears to be querying rsync to ask it what options
> it supports, and combining that list with the list in _rsync.

It would be nice if this feature could be used to remove options that
are defined in the _rsync script but not in the --help output.  The
latest version of _rsync in CVS now defines all the options through the
latest 2.6.3 version, but if the user is running a patched up 2.5.5
(e.g. debian stable), it would be helpful to the user if all the 2.6.x
options were not completed.

..wayne..

Re: characters not added in _rsync completion

[Bart Schaefer]

On Wed, 13 Oct 2004, Wayne Davison wrote:

> On Tue, Oct 12, 2004 at 11:41:52PM -0700, Bart Schaefer wrote:
> > I'm puzzled why the version of rsync itself makes any difference,
> > because _rsync specifies everything explicitly, so unless you've
> > edited _rsync it won't ever complete those options.
> 
> This is not how it works on my system.  The _rsync script appears to be
> querying rsync to ask it what options it supports, and combining that
> list with the list in _rsync.

I've belatedly spotted that _rsync does in fact pass the "--" option to
_arguments, which causes it to parse the --help output.

> > Without plunging into the why of it, a cursory inspection seems to 
> > indicate that when an option has an argument then zsh fails to find 
> > the longest common prefix among that option and any other options that 
> > do NOT
> 
> It's strange that the --no<TAB> case doesn't match this idea.

Hrm.  Well, I did say it was a cursory inspection.

Fooling around with how this behaves in interactive menu selection is ... 
unfortunately pretty much the opposite of "enlightening."