From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14225 invoked by alias); 28 Sep 2014 18:47:40 -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: 33266 Received: (qmail 2770 invoked from network); 28 Sep 2014 18:47:28 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140928114721.ZM27218@torch.brasslantern.com> Date: Sun, 28 Sep 2014 11:47:21 -0700 In-reply-to: <5427DE81.3080308@gmail.com> Comments: In reply to Vasiliy Ivanov "Re: _arguments not works as expected. Bug?" (Sep 28, 4:10pm) References: <54244804.8080305@gmail.com> <140926000210.ZM30825@torch.brasslantern.com> <5427DE81.3080308@gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: _arguments not works as expected. Bug? Cc: Vasiliy Ivanov MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 28, 4:10pm, Vasiliy Ivanov wrote: } } 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? Whether it's "important" would depend on whether many people complained about it when *using* the completions, not when writing the completion functions. I don't recall this complaint coming up before, though that doesn't mean it hasn't. However, in the context "important enough to attract anyone" I'm making somewhat euphemistic reference to the fact that zsh is entirely maintained by volunteers, so the things that get fixed are serious problems and easy cosmetic fixes, unless the issue actually interests someone who wants to dive into a difficult but mostly cosmetic problem. When the completion system was designed many years ago, there was such a person, but it's not so easy to find anyone now. } 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. Even in the best cases, completion is only supposed to provide reminders, help avoid typo errors, and fill in long strings such as file paths; it isn't meant to be able to enforce correctness of the command. I think something like _arguments '(-)-h' '(-h)'{-a,-b} - '(exclusive)' '(-h)'{-k,-l,-m} expresses all of that except the part about multi-option words. I would have thought that _arguments : '(-h)'{-a,-b} - '(exclusive)' {-k,-l,-m} - help -h would also have worked, but for some reason the (-h) exclusion doesn't work when formulated that way; perhaps someone would be interested in tracking *that* down.