Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Strange completion display with wrong matcher-list
- X-seq: zsh-workers 40292
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: martin@xxxxxxxx
- Subject: Re: Strange completion display with wrong matcher-list
- Date: Sat, 07 Jan 2017 10:39:49 +0100
- Cc: zsh-workers@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1483782015; bh=upwsQpPKEVExxbnHJgQqtejczIlYOP4dZ8zjSGId2mA=; h=cc:In-reply-to:From:References:To:Subject:Date:From:Subject; b=rCdazSeWFymrHfvxtQv7kFZil/F739M6v4JPmA5OtW5cUbsEBaeX5/IsH8WOTmMLlV2w1lrqAvitxSyMQ28PUt8xk1eh8w/iWG5m6hkmAmAi/nSYXnVsUGv0RWXnUFjEdRtvm5hUKzRWeX6qXvLfVLJeqgRtSZ1JJ7d9CbtGPX760EwBfrtKrVBJmyOaqNYkyhgqP91Pa0eSe+pTaa+C0cN0m/KU7EQMrrd9l393g/inP7IymUJCZdGR8PEtTXIhryEAArkUqDlGRvUBdSn5XY6xJw/L1zfqUSK2A403QNDMdfbwM1wtOpxtolcwAJVPa4C78VhuUATvCGbnt2DbEg==
- In-reply-to: <slrno717cn.509.martin@lounge.imp.fu-berlin.de>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <slrno717cn.509.martin@lounge.imp.fu-berlin.de>
Martin Vaeth wrote:
> Is the following a bug in zsh?
Not as such, there's a problem in your _my function, though it would
be nice if zsh could avoid the messed up display.
> zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}'
>
> I had copied it somewhere from the net, but it seems
> to me now that the first entry (the empty string) is buggy.
> However, instead of an error message or reliably wrong behaviour,
> it triggers a very strange thing.
What it says is that completion should first try no matcher. If that
fails, it will try again with case-insensitivity enabled.
The return status of completion functions is used to indicate success or
failure and usually corresponds to whether any matches were added. The
path through your function goes as follows:
+_my:3> _arguments -C : '(--long)-s[an option]' '(-s)--long[an option]' '1:an arg:->cmds'
+_my:6> local ret=0
+_my:7> case cmds (cmds)
+_my:9> _files
+_my:10> ret=1
+_my:12> return ret
_arguments added matches, _files didn't but the return status from files
_is used meaning that _my indicates failure. The result is that this is
_run a second time with the different matcher.
To fix your function, start it with local ret=1 and put && ret=0
after both _arguments and _files.
> For some(!) completion functions in some(!) zsh versions,
> when I press "tab" twice, the display of the options is broken.
You can see the same effect with the following function:
_my () {
_arguments {-s,--long}'[an option]'
_arguments {-s,--long}'[an option]'
}
_describe will also show the effect. Laying out the descriptions
assumes (and requires) full control of the group of matches. It's
never a good idea to mix more than one call to _arguments, _describe
or _values. Even if the tags differ, someone might not have the
group-name style set.
zsh internals see 6 display strings: the two options plus the
description which is padded with spaces so is very long. _describe
forces a column first layout and fixed match order. The two
descriptions will not fit side-by-side due to the padding so it
lays them out in a single column. When I wrote _dates, which uses
a rows first layout, getting the padding right was very tricky. The
internals could be improved to make it easier, at the very least
allow auto-padding of a hidden match. Changing _describe to use row
first ordering would help with this issue but repeated tab presses
would then cycle matches in a less ideal order.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author