zsh-workers
 help / color / mirror / code / Atom feed
* using tag-order with _pids
@ 2014-07-22 10:31 Oliver Kiddle
  2014-07-23  3:58 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Oliver Kiddle @ 2014-07-22 10:31 UTC (permalink / raw)
  To: Zsh workers

The patch below moves the use of _call_program by _pids to inside the
_tags loop. Much of the patch is just reindentation. The purpose of this
is to allow separate processes to be grouped so _next_tags can expand
the list to include a wider range of processes. So for example:

  zstyle ':completion:*:kill:*:' tag-order processes:-tty \
      'processes:-mine:user\ processes' 'processes:-all:all\ processes'
  zstyle ':completion:*:processes-mine' command 'ps -u $EUID'
  zstyle ':completion:*:processes-all' command 'ps -e'

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.

Oliver

diff --git a/Completion/Unix/Type/_pids b/Completion/Unix/Type/_pids
index 3f99dfd..3c6a765 100644
--- a/Completion/Unix/Type/_pids
+++ b/Completion/Unix/Type/_pids
@@ -20,25 +20,30 @@ else
   nm="$compstate[nmatches]"
 fi
 
-out=( "${(@f)$(_call_program processes ps 2>/dev/null)}" )
-desc="$out[1]"
-out=( "${(@M)out[2,-1]:#${~match}}" )
-
-if [[ "$desc" = (#i)(|*[[:blank:]])pid(|[[:blank:]]*) ]]; then
-  pids=( "${(@)${(@M)out#${(l.${#desc[1,(r)(#i)[[:blank:]]pid]}..?.)~:-}[^[:blank:]]#}##*[[:blank:]]}" )
-else
-  pids=( "${(@)${(@M)out##[^0-9]#[0-9]#}##*[[:blank:]]}" )
-fi
-
-if zstyle -T ":completion:${curcontext}:processes" verbose; then
-  list=( "${(@Mr:COLUMNS-1:)out}" )
-  desc=(-ld list)
-else
-  desc=()
-fi
-
-_wanted -V processes expl 'process ID' \
-    compadd "$@" "$desc[@]" "$all[@]" -a - pids && ret=0
+while _tags; do
+  if _requested processes; then
+    while _next_label processes expl 'process ID'; do
+      out=( "${(@f)$(_call_program $curtag ps 2>/dev/null)}" )
+      desc="$out[1]"
+      out=( "${(@M)out[2,-1]:#${~match}}" )
+
+      if [[ "$desc" = (#i)(|*[[:blank:]])pid(|[[:blank:]]*) ]]; then
+	pids=( "${(@)${(@M)out#${(l.${#desc[1,(r)(#i)[[:blank:]]pid]}..?.)~:-}[^[:blank:]]#}##*[[:blank:]]}" )
+      else
+	pids=( "${(@)${(@M)out##[^0-9]#[0-9]#}##*[[:blank:]]}" )
+      fi
+
+      if zstyle -T ":completion:${curcontext}:$curtag" verbose; then
+	list=( "${(@Mr:COLUMNS-1:)out}" )
+	desc=(-ld list)
+      else
+	desc=()
+      fi
+      compadd "$@" "$expl[@]" "$desc[@]" "$all[@]" -a pids && ret=0
+    done
+  fi
+  (( ret )) || break
+done
 
 if [[ -n "$all" ]]; then
   zstyle -s ":completion:${curcontext}:processes" insert-ids out || out=menu


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: using tag-order with _pids
  2014-07-22 10:31 using tag-order with _pids Oliver Kiddle
@ 2014-07-23  3:58 ` Bart Schaefer
  2014-07-31 16:30   ` Oliver Kiddle
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2014-07-23  3:58 UTC (permalink / raw)
  To: Zsh workers

On Jul 22, 12:31pm, Oliver Kiddle wrote:
} Subject: using tag-order with _pids
}
} The patch below moves the use of _call_program by _pids to inside the
} _tags loop.

So ... before, there was no _tags loop at all.

} Much of the patch is just reindentation. The purpose of this
} is to allow separate processes to be grouped so _next_tags can expand
} the list to include a wider range of processes.

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
column the actual PID is in, the style could potentially specify that
the pattern had to match in a particular column.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: using tag-order with _pids
  2014-07-23  3:58 ` Bart Schaefer
@ 2014-07-31 16:30   ` Oliver Kiddle
  2014-08-04 17:47     ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Oliver Kiddle @ 2014-07-31 16:30 UTC (permalink / raw)
  To: Zsh workers

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: using tag-order with _pids
  2014-07-31 16:30   ` Oliver Kiddle
@ 2014-08-04 17:47     ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2014-08-04 17:47 UTC (permalink / raw)
  To: Zsh workers

Sorry for slow response, I was out of town for a few days.

On Jul 31,  6:30pm, Oliver Kiddle wrote:
}
} For now, I can use a hack with zstyle -e. I think the _pids change is
} fairly harmless unless anyone objects?

I think both the _pids and _kill patches are fine.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-08-04 17:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-22 10:31 using tag-order with _pids Oliver Kiddle
2014-07-23  3:58 ` Bart Schaefer
2014-07-31 16:30   ` Oliver Kiddle
2014-08-04 17:47     ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).