From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11016 invoked by alias); 30 May 2018 12:47:14 -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: 42884 Received: (qmail 1495 invoked by uid 1010); 30 May 2018 12:47:14 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f175.google.com 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(209.85.128.175):SA:0(-3.6/5.0):. Processed in 1.362807 secs); 30 May 2018 12:47:14 -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=-3.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: doron.behar@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YEmuycTNY1LO0ycSpgwGwPISDY4gRxfRdOwVWI9fH2o=; b=bqouCzc1Jq3IXKbcjFFZaJh/xUZ8zLokQl/wCkLDZ9EFOr4ZMAhnyc/STnpOV6H6WC thtX2QjklJhcR9bz9V1UygZHF2DkV8E4Vh+t7pihoci3RtEjthXVfKIhBxrWddTTJEw/ uAWCboQLD6uTWegb8D90oft/JLgsQvACn0wCdNkRs9Myukm/AHyc6myZf7/xiNYEtU7E J6iNpeJKqm8RMNOu9GnbxqVENl9FmxiOi6tROr17pGnulexnVjSIxmZAWPo6SdknuAfE gIuNV9pohDCM0hq6tgdpFzhuF48lFatmuAQWu4BFn40X2gWcylUYLuwLns1KuSUe7/3p Wi0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=YEmuycTNY1LO0ycSpgwGwPISDY4gRxfRdOwVWI9fH2o=; b=uGFfgM/Ezc/BzSSXuWtzwYQnfAiaLUfXK4CHxmvgWtx7RPfip89al6wCFxQSA743OP 5TDliQLq2/f8g4814WUA4DCMQ/uu/FilX0wToQ1clKAkfz3K/KWrt2a2mQZyK5khqUS4 3bz9tOTjcH4eXIuseHIV7jqb5+aTSlPr+eji+7Z/05P/1wpr39t3YRFfF3H4QvcgvaBZ 7z6rmtGFTX9FlyZLJ8df6SGnYyGvYsZVzfyaxKrLH4Vm2Wc2JZdh1PRnhc0hgbPG8XnY C1cAynm/XUdW40vectzKaRzGxNfsPbWrcSRwz09eDQzMxKnxkDUMUnGkwDhxM5vQ/igU 3KyQ== X-Gm-Message-State: ALKqPwfbiZ+B2QUmh3rK1n3SB4CO4Bzd6jm1SiLuT3//ET52GvqSyzF+ zWUFbA8mjRaJAJTKD+GES3GZDzm6 X-Google-Smtp-Source: ADUXVKLDVn/oW9dsFPS6tw1ubRWP8fkjld2a19fLnNrfeCQO6w8+niPEwMuR4RnLWRuTqzZ1wny7jw== X-Received: by 2002:adf:f482:: with SMTP id l2-v6mr1731855wro.259.1527684427656; Wed, 30 May 2018 05:47:07 -0700 (PDT) Date: Wed, 30 May 2018 15:47:11 +0300 From: Doron Behar To: zsh-workers@zsh.org Subject: Re: [PATCH 1/1] Squashed commit of the following: Message-ID: <20180530124707.xp6loetwnplkypk2@NUC.doronbehar.com> Mail-Followup-To: zsh-workers@zsh.org References: <20180526161403.4860-1-doron.behar@gmail.com> <20180526161403.4860-2-doron.behar@gmail.com> <5942.1527504539@thecus> <20180529153821.nmwa5yojlusioxti@NUC.doronbehar.com> <13666.1527631249@thecus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <13666.1527631249@thecus> User-Agent: NeoMutt/20180512 Thank you Oliver for your guidance, The revised patch is ready I'll send it shortly, here are some more questions / comments I had regarding your last reply. On Wed, May 30, 2018 at 12:00:49AM +0200, Oliver Kiddle wrote: > 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. It's great, thanks! > > > 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. Got it. > > > 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. I copied `__git_tags`s content straight from `_git`s definition and added a comment stating so. > > > > 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. > Got it. > > > 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. This is what I chose: '--lib=[comma separated list of C library files to link to]:library files' > > > 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". O.K, I used `ret` instead yet currently I don't see any use in this variable since I didn't structured the completion file with `return ret` at the end of any of the functions as I've seen in other completion functions I read. > > 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 Jesus, using `zstyle` is complicated, I hope I'll master this skill one day.. Where can I find in the documentation more explanations about the relation between zstyle and completion functions?