From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8529 invoked by alias); 31 Jul 2014 16:37:53 -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: 32925 Received: (qmail 13165 invoked from network); 31 Jul 2014 16:37:40 -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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1406824254; bh=JbmOZUewjnihIXwm8crdlXAFlgLSJVMf6HME6bgm2kQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:In-reply-to:From:References:To:Subject:MIME-Version:Content-Type:Content-ID:Date:Message-ID; b=0Xdutuct1i3rupp4cUt1wDt4WHP1MZG2n2ps5e6M4OqKLLZysX8Zgjawf+47huVa8QwQ58gKkDcCY2qy0b8y8PgucY1/6Mu6oirxtWFqDWXd5mxOwkaprrpOZNRC4Amv0uAKprMy+jqpwgZiKa8hkCFYzPZL8OSHMNMwy8ag/V0= X-Yahoo-Newman-Id: 156254.30087.bm@smtp134.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: U3kr7f4VM1nQGQveJFLfd7FoxqE3z6IhBhej1bOkG8xh_PN 5MxnmRwlHXPXSv4oFauEADiIUoVxAfQ.BFJjYa6Jcommb0JvhXSAY.gjAsU5 fxaDvQqzkGaojCHOzRo3PZlwsUwPMEB6ib6rH8wMRBfi.U0x_HAOWUHhH6U_ Vvez2603JTvzj.W3psdJL_5b8ozKCEtUvuxJgPt5g1xNSHLX.eO6Ed6nMgHP uLKxY6gyjhoGaDg7rRE2z6dLgUNhY8H3b80XGK204PvZMBOglNZqm3y2KvoJ hP0G8486Ab4.ZUYusScJE.ooOTtb2Qtzn6HhCWAtx6_eOnXlhx8.JtkUgHCS WDuwb6ARGN1ix75eWCnhhMfgAwOVfkpBdb6d4Ji1EawrmV0o_FhxOBVgDofC d_HGFFfRjwLvjYDFTazPg2JddcWRNUlso96b_7fepKbKzLCELvgj3wgFZN77 8e7nlDB3HGJi1AAuTF7ih3HTwECiFgO_3ZtGlkyBXvzPHZ77XoOVDXnUjowL bjhItTO7Ycwot_wRj0YQLnPBskEQcTuw- X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: <140722205805.ZM23154@torch.brasslantern.com> From: Oliver Kiddle References: <18723.1406025098@thecus.kiddle.eu> <140722205805.ZM23154@torch.brasslantern.com> To: Zsh workers Subject: Re: using tag-order with _pids MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14860.1406824252.1@thecus.kiddle.eu> Date: Thu, 31 Jul 2014 18:30:52 +0200 Message-ID: <14861.1406824252@thecus.kiddle.eu> On 22 Jul, Bart wrote: > So ... before, there was no _tags loop at all. Well before it used _wanted which is just a wrapper to give you an _tags loop when you only have one tag. > Maybe another way to do this is to keep a single _call_program outside > the new _tags loop, and use a new zstyle inside the loop to partition > the "ps" output by pattern matching? > Since _pids is already "parsing" the ps header line to figure out what It's an interesting idea and I did some experimenting to test it. Certainly we have some precedent given that _files does something similar. The filtering isn't trivial and ends up requiring that you include fields (such as tty and user) that you don't want in the match descriptions because they'll be identical for all matches after filtering. It's possible for the new style to be limited to doing the partitioning (leaving _call_program/ps to provide filtering) but we're supposed to already have a feature for partitioning tags with tag labels. It might be better to see if the tag-order lookup can be somehow improved: perhaps include the tag from an outer tag-loop when nesting them. For now, I can use a hack with zstyle -e. I think the _pids change is fairly harmless unless anyone objects? I wrote: > There are some things that aren't ideal about this: the tag-order style > has to be defined for e.g. the kill command and can't apply whenever > _pids is called. Also an ambiguous prefix from the first tag limits > matches in later tags. If anyone has any ideas on solutions to these > issues, I'd be interested to know. A solution to the latter issue is to add a hidden match (compadd -n) alongside the real matches. It's possible to do that with zstyle but in the case of kill, it occurred to me that 0 is a valid match, along with negative numbers, to send a signal to a process group. I've attached a patch to _kill, more to demonstrate this than because completing 0 after kill is especially useful. You can use the hidden style to hide it or add -n explicitly. Unfortunately, with menu completion, hidden matches become visible (and I set the menu style for process completion). Any thoughts on whether the patch should be applied? Oliver diff --git a/Completion/Zsh/Command/_kill b/Completion/Zsh/Command/_kill index 5e52a99..b9dfde3 100644 --- a/Completion/Zsh/Command/_kill +++ b/Completion/Zsh/Command/_kill @@ -1,6 +1,7 @@ #compdef kill local curcontext="$curcontext" line state ret=1 +typeset -A opt_args _arguments -C \ '(-s -l 1)-n[specify signal number]:signal number' \ @@ -10,9 +11,12 @@ _arguments -C \ '*:processes:->processes' && ret=0 if [[ -n "$state" ]]; then + local pgrp='process-groups:: _wanted ' + [[ -n "$opt_args[(i)-[ns]]${${(@)line:#--}}" && -prefix - ]] && pgrp+='-x ' + pgrp+="process-groups expl 'process-group' compadd - 0" _alternative \ 'processes:: _pids' \ - 'jobs:: _jobs -t' && ret=0 + 'jobs:: _jobs -t' $pgrp && ret=0 fi return ret