Zsh Mailing List Archive
Messages sorted by:
Re: _arguments not works as expected. Bug?
- X-seq: zsh-workers 33260
- From: Vasiliy Ivanov <beelzebubbie.logs@xxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: _arguments not works as expected. Bug?
- Date: Sun, 28 Sep 2014 16:10:09 +0600
- Cc: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XsKJIp06KPvkb8f1tX1Qnkim4DyhZQOdz81nla9IKFI=; b=pxuIsQ12H+N2OIYihw1BR1Pix92/SvvPlbKM6QP6DnI2l3j6CqOB7YbAwiCRWDhSWh QqQvaS8oHYQBKbMKJNx5yFPM1m1OXKMITly0IEGH6VOVMZ0VQ8WNso6p1XVOTnG+CGAU RqKc+3J9zlukFIgIdaWS7ymFG5lvTzFwN7RnshOFRhqAAKcTJiRNx8yzsUSIc+I00Boj CyVhF8Q5AmQq7IvMxplEE1MxKeTGzDnML/LWyX5QjJdodMD063+nYxhkvHHYkyg3itBH 6uoRgwqQMweNLSZBHyGQg+cp3oam2+8k/IT3bW58uXrXc3mDlDRd6dmKp9usVwibB/dE uKGA==
- In-reply-to: <140926000210.ZM30825@torch.brasslantern.com>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <email@example.com> <140926000210.ZM30825@torch.brasslantern.com>
On 26.09.2014 13:02, Bart Schaefer wrote:
> On Sep 25, 10:51pm, Vasiliy Ivanov wrote:
> } % testcmd -q <tab> producing only -q completion as expected (as -q excludes only -v), but:
> } % testcmd -q<tab> offered both -q and -v (why?)
> As you might expect, it has to do with the implementation of -s and
> the way completion always operates on a single word.
> In order to complete from "x" to "xy" or "xyz", compadd has to be told
> the set of all full words that might appear in that position. It then
> filters out the words that don't match.
> Because of this, when you use "_arguments -s" and the context is the
> middle of a word that appears to be multiple single letters, the words
> passed to compadd have to be constructed by pasting together letters
> from the set of all possible single letter arguments. Thus if there
> are single letter options -m, -n, and -o, and -m already appears, then
> _arguments constructs the words -mm (if -m is repeatable), -mn, and
> -mo, and passes those to compadd, because those are all the possible
> words that begin with -m in that context. [*]
> The complication is that it is the script that constructs -mn and -mo,
> but the "exclusion list" definition is parsed by the "comparguments"
> builtin and isn't available to the script; instead it's applied by
> the internals when "compadd" is finally called. So the script does
> not "know" that it could drop some of those letters when generating
> the possible permutations; it just generates all of them.
> Down in compadd, the exclusion list operates on full words, not on
> substrings. (-v)-q doesn't mean to exclude "v" from words beginning
> with "-" of which it is a substring, it means to exclude the word
> "-v". Since the words passed to compadd in this example are "-qq"
> and "-qv", neither matches "-v" and so both are offered as valid
> So now you have the answer to "why?". Preventing it from happening
> would require new C code (another option to "comparguments" perhaps?)
> and/or some hairy script work to explode the word on the line out to
> its individual letters, filter them, and glue them back together.
> The particular feature of having exlusions work on multiple options
> packed into the same word has not so far been considered important
> enough to attract anyone willing to do that work.
> [*] It would also work for it to ignore the fact that -m is already on
> the line and generate -no, -om, etc., and allow comparison to the word
> on the line to filter out the ones not starting with -m, but it tries
> to do a small amount of optimization.
Thanks for detailed clarification. I see all complications, but also I see that very powerful
_arguments function looks slightly «incompleted» itself. Lot of people used only «basic» _arguments'
functionality – maybe because of lack of consistency in «extended» functional. Maybe this
inconsistency is not «important enough» because of hard to use?
For instance, I tried to implement simple scenario:
command have a couple of «common» options: -a and -b; a few of mutually exclusive options: -k,-l,-m;
and a -h option that could be used only alone. Exclusion sets are not nested, so I can't implement
logic as «-h or (-a,-b (-k or -l or -m))». I can use prepending exclusion lists, but they aren't
worked with -s so I have to deny multi-option words though exclusions sets do their work even in
multi-option words. Very pity.
As a result, I failed to implement proper completion logic and forced to fallback to «simple» way –
all options in one heap. In my opinion, full absence of «exclusion» logic is better that *partial*
implementation because it is more predictable for user.
Sorry for my English :)
Vasiliy Ivanov <beelzebubbie.logs@xxxxxxxxx>
Messages sorted by: