From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11013 invoked by alias); 29 May 2018 22:01:16 -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: List-Unsubscribe: X-Seq: 42880 Received: (qmail 8839 invoked by uid 1010); 29 May 2018 22:01:16 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(-1.4/5.0):. Processed in 1.196682 secs); 29 May 2018 22:01:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=ogym=IQ=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1527631253; bh=tK5TP1BLaX/oUU1zSGFkLlvyWl11n/oNtfOru3fIHao=; h=From:References:To:Subject:Date:From:Subject; b=a4qRrnMgD5ZxWC1B7eQYe4RseIdGtXlUowq0nimSpNLwLkW3zYgPyI2E62w7bb4q0enwdEqf0m75ted+aUDwOZL83KdN4vOxUXIuEQnL6/s2+7xmd2me44IHtoP1H1W+MAZoLDzSRUJM6p4ZmRL8SUkwfpd9bC7bgfIbVEDxbrGRhWQfDIqE62nMqVw5aQ1nObQGe4+wIH6ObsWHvnxFENQ1XogI/Rpmx5FW9Fwc9x2hSldYeSYS1Er+LTRNMj+SpKvMKfi0vqCHhrUkuTI6wYg6FedvAWv0PLcIT8XazBTFa2HZVF4NmmjxxdoPyT2GUsE65k1F+bc7EFViMUAxtA== X-YMail-OSG: WbtbyDkVM1loSYLb_TBw5kCyfl8dsfa20VYfV4ZZbWr9MpRxM9FrPRtlZI6zWbD NI1_9pPrSkPNLnwb_blO5j24XxPKldp4epAqm8yVEhwmPSOUWelsqTnDlyUvzRcovLb_aUzhPENv 2KhTq_6QyZiQQQdMzZIhdFH7u1S62P3nybivLFGJJRfdqgkhAeJb2S0ItFlVjZXFElm0yQr3tbyG XNjxtK..M6o30uRN8VnoC2YtfTm_uzEXNlie7Fiac8u5O2ZYsEIwCF_kKBTlMZN7Y8jLXMxrVjVF 88m9Ecliw03c2t_FJh_E6afAlIlKVh14JTaSEG8HdhtbLLdAXRqBS4ac4sZ.SDTixcL9o__UHarf 55hIULE8Z5fqdyjHNJgOYnZSIcda5H64jh6zdHs4BZsarFAxIR6q0lhY363_shV2cdCDAYPqNIy3 LkHYgYJ9TkxJ7unYuxEaGbgjYtoss6w.2Tbl6WEgpLBOkrmpxHOilGBNu5y72WOVkqx5UU5ADSPk y6Ln0.qoxMDaaH4cbtksz6kyRUq9e3pYGd10327Dm4RByLD4wSfgK3MA1Tyc4ObMjRuY8lknMXGU BN0HALhrrFMBGnGeaNitqYJRrZI6vvJQHmi3h.U1jVEFmI1ho.dUY0ANIkxiP84vXIu38uxWKLV5 P0Feicv0hHZM0jXIu In-reply-to: <20180529153821.nmwa5yojlusioxti@NUC.doronbehar.com> From: Oliver Kiddle References: <20180526161403.4860-1-doron.behar@gmail.com> <20180526161403.4860-2-doron.behar@gmail.com> <5942.1527504539@thecus> <20180529153821.nmwa5yojlusioxti@NUC.doronbehar.com> To: zsh-workers@zsh.org Subject: Re: [PATCH 1/1] Squashed commit of the following: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13665.1527631249.1@thecus> Date: Wed, 30 May 2018 00:00:49 +0200 Message-ID: <13666.1527631249@thecus> Doron Behar wrote: > > I find that extremely useful when I write completions since it's super > comfortable with my editor (Vim). Do you have any suggestions? Perhaps > using EditorConfig? I don't think editorconfig supports much beyond basic definitions of indent style. In the case of vim, it supports a variety of foldmethods. 'set foldmethod=syntax' doesn't do such a bad job and if you don't like it you can define custom expressions. > Done, used this: > > local option_deps_modes='--deps-mode=[specify how to handle dependencies]:mode:__luarocks_deps_modes' That looks fine. > Besides removing the curly brackets, what is the difference when I use > '(-.)' in the glob and when I don't? I tried to test this in directories > where I had files ending with `.rockspec` and in directories where I > hadn't had files like these and I couldn't tell the difference in > behaviour. What am I missing? It can make a difference if you have directories ending in .rockspec. That perhaps isn't common but in some contexts it can matter. It is common to setup the file-patterns style to mix directories in with matched files in which case it is less apparent. For reference, see the old discussion around workers/19292. > I couldn't think of a better way of doing this other then just copying > manually `__git_tags` or using this hack. Duplicating __git_tags' functionality is just as few lines of code and less likely to break. This looks rather fragile. > > In this spec, you already have already specified a message - "LICENSE" > > so calling _message is superfluous. "LICENSE" can be improved on as a > > message but I'd avoid constructs like "write a" and use something like > > 'license (e.g. MIT/X11 or "GNU GPL v3")' > > That's a good description, cool. I've come up with this options > specifications: > > '--license=[a license string]:license:{_message -e license "(e.g. \"MIT/X11\" or \"GNU GPL v3\")"}' My point about calling _message being superfluous perhaps wasn't clear. The second part of the colon-delimited spec IS a message. So you can just use: '--license=[specify a license string]:license (e.g. "MIT/X11" or "GNU GPL v3")' Note that I also added an initial verb in the description which was a suggestion I had made earlier but not repeated. > > Your description, looks like the message for the matches: > > '--lib[specify libraries to link against C files]:libraries (comma-separated)' > > > > Or use _sequence or _values if you generate matches. > > > > I've no idea if this is possible to complete matches for this option. I > don't have any experience in using this option as well so I'll leave it > this way. Perhaps it'll be better for the specification to be this: > > '--lib=[C library files to link to]:' At least include a message after the colon. > I'm not sure I understand yet what tags are used for generally in > completions (RTFD I know but forgive me I'm lazy :/) but anyway the tag > I chose as the 1st argument for `_call_function` is `subcmd`. Is that > cool? It looks like that: > > _call_function subcmd _luarocks_${words[1]} The first argument to _call_function is not a tag but a variable name. The return status from the function is assigned to it. Normally, you'll see "ret". Tags are used with the zstyle mechanism. zstyle gives you context-sensitive options where a bunch of information is stuffed into a context string. For completion, :completion::::: Note that the last component is the tag for the current matches. This is a much more succinct and convenient way to configure things than if you needed lots of nested if statements. Taking an example from one of your messages we have: zstyle ':completion:*:kill:*' command 'ps -u $USER -o pid,%cpu,tty,cputime,cmd' As it happens, for kill completion the command style is only looked up when completing processes but it'd be wise to put the processes tag into the context there. If you want the style to work for all commands and not just kill, that'd be essential. Otherwise, it might run ps when generating some other entirely different sort of matches: zstyle ':completion:*:processes' command 'ps -u $USER -o pid,%cpu,tty,cputime,cmd' (To answer the question in that other post, don't try to emulate that, just use _pids and leave process selection to the user. ps defaulting to the current tty made more sense a couple of decades ago.) The other thing tags are often used for is for grouping completion matches. Groups are separate but it is common to use the tag as the group name which is what you get with: zstyle ':completion:*' group-name '' Finally, tags can be used with the tag-order style to allow users to try some matches before others. Oliver