Re: using tag-order with _pids

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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