From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25676 invoked by alias); 28 Sep 2014 10:10:28 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33260 Received: (qmail 2954 invoked from network); 28 Sep 2014 10:10:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 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== X-Received: by 10.112.129.71 with SMTP id nu7mr980798lbb.106.1411899011937; Sun, 28 Sep 2014 03:10:11 -0700 (PDT) Message-ID: <5427DE81.3080308@gmail.com> Date: Sun, 28 Sep 2014 16:10:09 +0600 From: Vasiliy Ivanov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: zsh-workers@zsh.org CC: Bart Schaefer Subject: Re: _arguments not works as expected. Bug? References: <54244804.8080305@gmail.com> <140926000210.ZM30825@torch.brasslantern.com> In-Reply-To: <140926000210.ZM30825@torch.brasslantern.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.09.2014 13:02, Bart Schaefer wrote: > On Sep 25, 10:51pm, Vasiliy Ivanov wrote: > } > } % testcmd -q producing only -q completion as expected (as -q excludes only -v), but: > } % testcmd -q 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 > completions. > > 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 :) -- Regards, Vasiliy Ivanov