Redirection completion

Redirection completion

[Peter Stephenson]

I'm just amusing myself between tasks by playing with the new system for
completing redirections.

Is the patch at the end useful?  I got caught out because I originally
defined a completion for a non-existent type `redir'.  The list of types
appears to be closed --- i.e. you can't add your own because they're
handled internally --- in which case it's safe to test the type.

Next, it looks like the context for redirections isn't all that helpful
at the moment.  After `echo 2>' I seem to get just
`:completion::complete:echo::'.  Could we have something like the way
arguments work, so that it at least indicates we're in a redirection,
and preferably also the `2>' bit?  Along the lines of
  :completion::complete:dvips:option-o-1:
I would suggest
  :completion::complete:echo:redir-2>:'
for `echo 2>'.

Another point is that I don't seem to be able to supply completions for
`2>|' and so on, but maybe I haven't tried hard enough.

(What I was trying to do, for orientation, was make completion after any
`2>' prefer to send output to local files with the suffix `.log'.  I
came up with this:


#compdef -T redirs 2> 2>>

local expl

_wanted logfiles expl 'log files' _path_files -g "*.log" && return 0
_wanted all-files expl 'all files' _files


This always prefers log files, and it would probably be nicer to use
_alternative.  But then I need a tag order to make sure they don't all
get shown at once, and for that I need a context.  At least, I think.
Thinking some more, I could probably do all this more easily with
file-patterns, but that definitely requires more specific context
information.)

By the way, I think I'm going to expand the user guide to include more
recipe-style information.  If anyone wants to send me a list of stuff
that can be done that's not described at the moment (see
http://zsh.sunsite.dk/Guide/zshguide06.html) I'll add it.

Index: Completion/compinit
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/compinit,v
retrieving revision 1.7
diff -u -r1.7 compinit
--- Completion/compinit	4 Mar 2002 08:53:42 -0000	1.7
+++ Completion/compinit	8 Mar 2002 11:55:48 -0000
@@ -412,6 +412,11 @@
             echo "$0: missing type"
             return 1
           fi
+	  if [[ $1 != (comps|redirs|values) ]]; then
+            print \
+              "compinit: Warning: completion type \`$1' is not supported.
+Supported types are comps, redirs, values." >&2
+          fi
           _comp_assocs=( "$_comp_assocs[@]" "$1" )
           typeset -gA _$1 _service$1 _pat$1 _postpat$1
           assoc="$1"
@@ -441,6 +446,10 @@
       if (( ! $# )); then
         echo "$0: missing type"
         return 1
+      fi
+      if [[ $1 != (comps|redirs|values) ]]; then
+         print "compinit: Warning: completion type \`$1' is not supported.
+Supported types are comps, redirs, values." >&2
       fi
       _comp_assocs=( "$_comp_assocs[@]" "$1" )
       typeset -gA _$1 _service$1 _pat$1 _postpat$1

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Redirection completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> Is the patch at the end useful?  I got caught out because I originally
> defined a completion for a non-existent type `redir'.  The list of types
> appears to be closed --- i.e. you can't add your own because they're
> handled internally --- in which case it's safe to test the type.

Yes and no.  In its last incarnation, the types are completely defined
by the functions making use of them. compinit/compdef collects them
from the -T options it gets.

So, for the time being, the patch below is (almost) fine.  I was
thinking about people who might want to stuff calls to compdef into
the startup files and later (somehow) make the functions known that
use those completion types.  Maybe that's not really an issue, my
brain was getting pretty fuzzy at that time.

Anyway, `almost' because compdef updates the array _comp_assocs to
contain all completion type names it knows about, so the patch should
use that.

> Next, it looks like the context for redirections isn't all that helpful
> at the moment.  After `echo 2>' I seem to get just
> `:completion::complete:echo::'.  Could we have something like the way
> arguments work, so that it at least indicates we're in a redirection,
> and preferably also the `2>' bit?  Along the lines of
>   :completion::complete:dvips:option-o-1:
> I would suggest
>   :completion::complete:echo:redir-2>:'
> for `echo 2>'.

Hm, yes.  The strings given to _dispatch are currently only used for
lookup-as-in-command-name-lookup, not for context name lookup.  And
for redirections we use `command:op', so you can do e.g.:

  compdef '_files -g "*.log"' -T redirs 'echo:2>'
  compdef '_files -g "*.log"' -T redirs 'echo:2>|'

This should also work with pattern-completions... but not with a line
like the ones above, because _dispatch doesn't use eval for pattern
completions.  I've overlooked that and will produce a patch till next
week, together with a patch for:

I wasn't sure about using a colon to separate the command name from
the redirection operator anyway, but I simply forgot to stuff the
information into the context string.  That's a good idea, I'll do that
and put the fix with the missing `eval's into the same patch (should I
also include the change to make compdef() use _comp_assocs? saving you
some time?)

> ...
> 
> This always prefers log files, and it would probably be nicer to use
> _alternative.  But then I need a tag order to make sure they don't all
> get shown at once, and for that I need a context.  At least, I think.
> Thinking some more, I could probably do all this more easily with
> file-patterns, but that definitely requires more specific context
> information.)

Right.

> By the way, I think I'm going to expand the user guide to include more
> recipe-style information.  If anyone wants to send me a list of stuff
> that can be done that's not described at the moment (see
> http://zsh.sunsite.dk/Guide/zshguide06.html) I'll add it.

Sounds good, no ideas yet, will try to think of some...


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Oliver Kiddle]

 --- Peter Stephenson <pws@csr.com> wrote:

> Next, it looks like the context for redirections isn't all that
> helpful
> at the moment.  After `echo 2>' I seem to get just
> `:completion::complete:echo::'.  Could we have something like the way
> arguments work, so that it at least indicates we're in a redirection,
> and preferably also the `2>' bit?  Along the lines of
>   :completion::complete:dvips:option-o-1:
> I would suggest
>   :completion::complete:echo:redir-2>:'
> for `echo 2>'.

The context isn't too useful for values either. I'm not sure about
putting the information in the fifth (argument) part of the context.
For values the fourth (command) part is just set to -value-. What I
would suggest is that we use the fourth part of the context. It is
currently defined as the command so it would make sense to use it as
the dispatch key. So we could have contexts which are something like:

:completion::complete:-redirect-echo-2>:
:completion::complete:-value-GZIP:

Exact format could be different. My point is about what component of
the context is used.

> _wanted logfiles expl 'log files' _path_files -g "*.log" && return 0
> _wanted all-files expl 'all files' _files

This looks like another example of why default tag-orders as I
described before would be a good idea.

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: Redirection completion

[Peter Stephenson]

Aargh, forgot to send this to the list again.

Sven Wischnowsky wrote:
> (should I
> also include the change to make compdef() use _comp_assocs? saving you
> some time?)

You might as well, it's certainly less than urgent and you might notice
something I wouldn't.

Oliver wrote:
>> Along the lines of
>>   :completion::complete:dvips:option-o-1:
>> I would suggest
>>   :completion::complete:echo:redir-2>:'
>> for `echo 2>'.
>
> The context isn't too useful for values either. I'm not sure about
> putting the information in the fifth (argument) part of the context.
> For values the fourth (command) part is just set to -value-. What I
> would suggest is that we use the fourth part of the context.
>...
>
>:completion::complete:-redirect-echo-2>:
>:completion::complete:-value-GZIP:

I don't understand the reasoning:  why does this need to be different
from the way options or arguments work?  For redirection it would seem
to be a similar sort of case, where you might want to match on the
command name in the normal way.  Values certainly demand different
handling.  But then surely the logical thing is to keep the type
separate from the argument and have

:completion::complete:-value-:GZIP:

as the context?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Redirection completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> I don't understand the reasoning:  why does this need to be different
> from the way options or arguments work?  For redirection it would seem
> to be a similar sort of case, where you might want to match on the
> command name in the normal way.  Values certainly demand different
> handling.  But then surely the logical thing is to keep the type
> separate from the argument and have
> 
> :completion::complete:-value-:GZIP:
> 
> as the context?

In terms of nicely separated parts (of the context name) I'm with you,
but think of things like:

  LDFLAGS='-I<TAB>

I've got to play and think some more...


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Sven Wischnowsky]

Hi

Whew.  Thinking some more lead to the patch below which is probably
entirely different from what everyone expected.  It removes the -T
completion type handling again.  Ahem.  Let me explain.

Because of that `LDFLAGS=-I<TAB>' thing I mentioned I was definitely
preferring to put everything into the command/context part of the
context name because otherwise part of the information would get lost
later.  Then I was looking at it again and trying to imaginge what our
customers would think if they see that they have to use `-T values foo'
when defining functions but `-value-foo' when defining styles.  I
doubt they would understand it -- and they would be right, wouldn't
they?  And, besides, if we were to put the variable name or
redirection operator somewhere else in the context name this wouldn't
be much different.

So, I wrote the patch below.  Removing the -T stuff and consistently
using names like `-value-foo' or `-redirect-echo-2>' everywhere, both
for the context used for styles and for compdef/#compdef (that's why
we don't need separated sets of completion functions anymore).

The patch also contains the doc changes and a change to compdef so
that -p and -P can now e given like -T could be given before, i.e. in
a list of names, toggling to define patterns.  And a new -N can be
used to toggle back.

I'm not going to commit this patch before I get replies, but I like
it.  A lot.  Because it makes things easier without losing power.
One thing we could think about is a standard for offering more
information in the context name.  I used parts separated by hyphens
becuase that's what we used before for sub-commands, but maybe there's
a better way or more places where we can offer more information.

Comments?


Bye
  Sven

diff -ur -r ../oz/Completion/Base/Completer/_complete ./Completion/Base/Completer/_complete
--- ../oz/Completion/Base/Completer/_complete	Sun Mar 10 12:52:38 2002
+++ ./Completion/Base/Completer/_complete	Sun Mar 10 13:05:38 2002
@@ -95,7 +95,7 @@
 
 comp="$_comps[-first-]"
 if [[ -n "$comp" ]]; then
-  service="${_servicecomps[-first-]:--first-}"
+  service="${_services[-first-]:--first-}"
   ccarray[3]=-first-
   eval "$comp" && ret=0
   if [[ "$_compskip" = all ]]; then
@@ -124,7 +124,7 @@
   ccarray[3]="$cname"
 
   comp="$_comps[$cname]"
-  service="${_servicecomps[$cname]:-$cname}"
+  service="${_services[$cname]:-$cname}"
 
   # If not, we use default completion, if any.
 
@@ -134,7 +134,7 @@
       return 1
     fi
     comp="$_comps[-default-]"
-    service="${_servicecomps[-default-]:--default-}"
+    service="${_services[-default-]:--default-}"
   fi
   [[ -n "$comp" ]] && eval "$comp" && ret=0
 fi
diff -ur -r ../oz/Completion/Base/Core/_dispatch ./Completion/Base/Core/_dispatch
--- ../oz/Completion/Base/Core/_dispatch	Sun Mar 10 12:52:38 2002
+++ ./Completion/Base/Core/_dispatch	Sun Mar 10 14:09:39 2002
@@ -1,8 +1,7 @@
 #autoload
 
 local comp pat val name i ret=1 _compskip="$_compskip"
-local curcontext="$curcontext" service str comptype noskip def
-local __comps __patcomps __postpatcomps __services
+local curcontext="$curcontext" service str noskip def pre
 
 # If we get the option `-s', we don't reset `_compskip'.
 
@@ -17,17 +16,9 @@
 
 [[ -z "$noskip" ]] && _compskip=
 
-comptype=$1
+pre="$1"
 
-__comps=_$1
-
-(( ${(P)+__comps} )) || return 1
-
-__patcomps=_pat$1
-__postpatcomps=_postpat$1
-__services=_service$1
-
-shift
+set -- "$1${(@)^argv[2,-1]}"
 
 # See if there are any matching pattern completions.
 
@@ -35,9 +26,10 @@
 
   for str in "$@"; do
     [[ -n "$str" ]] || continue
-    service="${${(e):-\$${__services}[\$str]}:-$str}"
-    for i in "${(@e):-\$${__patcomps}[(K)\$str]}"; do
-      "$i" && ret=0
+    service="${_services[$str]:-$str}"
+    for i in "${(@)_patcomps[(K)$str]}"; do
+      curcontext="${curcontext%:*:*}:${str}:"
+      eval "$i" && ret=0
       if [[ "$_compskip" = *patterns* ]]; then
         break
       elif [[ "$_compskip" = all ]]; then
@@ -54,8 +46,8 @@
 for str in "$@"; do
   [[ -n "$str" ]] || continue
   name="$str"
-  comp="${(e):-\$${__comps}[\$str]}"
-  service="${${(e):-\$${__services}[\$str]}:-$str}"
+  comp="${_comps[$str]}"
+  service="${_services[$str]:-$str}"
 
   [[ -z "$comp" ]] || break
 done
@@ -64,20 +56,23 @@
 
 if [[ -n "$comp" ]]; then
   _compskip=patterns
+  curcontext="${curcontext%:*:*}:${str}:"
   eval "$comp" && ret=0
   [[ "$_compskip" = (all|*patterns*) ]] && return ret
 elif [[ "$_compskip" != *default* ]]; then
-  name=-default-
-  comp="${(e):-\$${__comps}[-default-]}"
+  name="$pre-default-"
+  comp="${_comps[$pre-default-]}"
+  [[ -z "$comp" ]] && name="-default-" comp="${_comps[-default-]}"
 fi
 
 if [[ "$_compskip" != (all|*patterns*) ]]; then
   for str; do
     [[ -n "$str" ]] || continue
-    service="${${(e):-\$${__services}[\$str]}:-$str}"
-    for i in "${(@e):-\$${__postpatcomps}[(K)\$str]}"; do
+    service="${_services[$str]:-$str}"
+    for i in "${(@)_postpatcomps[(K)$str]}"; do
       _compskip=default
-      "$i" && ret=0
+      curcontext="${curcontext%:*:*}:${str}:"
+      eval "$i" && ret=0
       if [[ "$_compskip" = *patterns* ]]; then
         break
       elif [[ "$_compskip" = all ]]; then
@@ -88,9 +83,10 @@
   done
 fi
 
-[[ "$name" = -default- && -n "$comp" &&
+[[ "$name" = *-default- && -n "$comp" &&
    "$_compskip" != (all|*default*) ]] &&
-  service="${${(e):-\$${__services}[-default-]}:--default-}" &&
+  service="${_services[$name]:-$name}" &&
+  curcontext="${curcontext%:*:*}:${name}:"
    eval "$comp" && ret=0
 
 _compskip=''
diff -ur -r ../oz/Completion/Base/Core/_normal ./Completion/Base/Core/_normal
--- ../oz/Completion/Base/Core/_normal	Sun Mar 10 12:52:38 2002
+++ ./Completion/Base/Core/_normal	Sun Mar 10 13:37:51 2002
@@ -22,4 +22,4 @@
 
 _set_command
 
-_dispatch -d "$skip[@]" comps "$_comp_command1" "$_comp_command2"
+_dispatch -d "$skip[@]" '' "$_comp_command1" "$_comp_command2"
diff -ur -r ../oz/Completion/Base/Utility/_set_command ./Completion/Base/Utility/_set_command
--- ../oz/Completion/Base/Utility/_set_command	Sun Mar 10 12:52:38 2002
+++ ./Completion/Base/Utility/_set_command	Sun Mar 10 14:09:51 2002
@@ -11,21 +11,16 @@
 
 if (( $+builtins[$command] + $+functions[$command] )); then
   _comp_command1="$command"
-  curcontext="${curcontext%:*:*}:${_comp_command1}:"
 elif [[ "$command[1]" = '=' ]]; then
   eval _comp_command2\=$command
   _comp_command1="$command[2,-1]"
-  curcontext="${curcontext%:*:*}:${_comp_command2}:"
 elif [[ "$command" = ..#/* ]]; then
   _comp_command1="${PWD}/$command"
   _comp_command2="${command:t}"
-  curcontext="${curcontext%:*:*}:${_comp_command2}:"
 elif [[ "$command" = */* ]]; then
   _comp_command1="$command"
   _comp_command2="${command:t}"
-  curcontext="${curcontext%:*:*}:${_comp_command2}:"
 else
   _comp_command1="$command"
   _comp_command2="$commands[$command]"
-  curcontext="${curcontext%:*:*}:${_comp_command1}:"
 fi
diff -ur -r ../oz/Completion/Unix/Command/_gcc ./Completion/Unix/Command/_gcc
--- ../oz/Completion/Unix/Command/_gcc	Sun Mar 10 12:52:38 2002
+++ ./Completion/Unix/Command/_gcc	Sun Mar 10 13:23:04 2002
@@ -1,13 +1,13 @@
-#compdef gcc g++ -T values LDFLAGS CFLAGS CPPFLAGS
+#compdef gcc g++ -value-LDFLAGS -value-CFLAGS -value-CPPFLAGS
 
 local curcontext="$curcontext" state line ret=1 expl args args2
 typeset -A opt_args
 
-if [[ "$comptype" = values ]]; then
+if [[ "$service" = -value-* ]]; then
   compset -q
   words=( fake "$words[@]" )
   (( CURRENT++ ))
-  if [[ "$service" = LDFLAGS ]]; then
+  if [[ "$service" = *LDFLAGS ]]; then
     args2=( '-R:runtime path:->rundir' )
   else
     args2=()
diff -ur -r ../oz/Completion/Unix/Command/_make ./Completion/Unix/Command/_make
--- ../oz/Completion/Unix/Command/_make	Sun Mar 10 12:52:38 2002
+++ ./Completion/Unix/Command/_make	Sun Mar 10 14:04:30 2002
@@ -45,6 +45,7 @@
     fi
     _wanted targets expl 'make target' compadd -a tmp && return 0
   fi
+  compstate[parameter]="${PREFIX%%\=*}"
   compset -P 1 '*='
-  _files
+  _value "$@"
 fi
diff -ur -r ../oz/Completion/Unix/Command/_su ./Completion/Unix/Command/_su
--- ../oz/Completion/Unix/Command/_su	Sun Mar 10 12:52:38 2002
+++ ./Completion/Unix/Command/_su	Sun Mar 10 13:37:36 2002
@@ -17,4 +17,4 @@
 shell="${${(M@)${(@f)$(</etc/passwd)}:#$usr*}##*:}"
 compset -n $base
 
-_dispatch comps $shell $shell:t -default-
+_dispatch -d '' $shell $shell:t
diff -ur -r ../oz/Completion/Unix/Type/_files ./Completion/Unix/Type/_files
--- ../oz/Completion/Unix/Type/_files	Sun Mar 10 12:52:38 2002
+++ ./Completion/Unix/Type/_files	Sun Mar 10 13:25:22 2002
@@ -1,4 +1,4 @@
-#compdef -T redirs -default-
+#compdef -redirect--default-
 
 local opts tmp glob pat pats expl tag i def descr end ign ret=1 match tried
 local type sdef
diff -ur -r ../oz/Completion/Unix/Type/_printers ./Completion/Unix/Type/_printers
--- ../oz/Completion/Unix/Type/_printers	Sun Mar 10 12:52:38 2002
+++ ./Completion/Unix/Type/_printers	Sun Mar 10 13:23:57 2002
@@ -1,4 +1,4 @@
-#compdef -T values PRINTER LPDEST
+#compdef -value-PRINTER -value-LPDEST
 
 local expl ret=1 list disp sep
 
diff -ur -r ../oz/Completion/Unix/Type/_terminals ./Completion/Unix/Type/_terminals
--- ../oz/Completion/Unix/Type/_terminals	Sun Mar 10 12:52:38 2002
+++ ./Completion/Unix/Type/_terminals	Sun Mar 10 13:24:06 2002
@@ -1,4 +1,4 @@
-#compdef infocmp -T values TERM
+#compdef infocmp -value-TERM
 
 local desc expl
 
diff -ur -r ../oz/Completion/Unix/Type/_time_zone ./Completion/Unix/Type/_time_zone
--- ../oz/Completion/Unix/Type/_time_zone	Sun Mar 10 12:52:38 2002
+++ ./Completion/Unix/Type/_time_zone	Sun Mar 10 13:24:20 2002
@@ -1,4 +1,4 @@
-#compdef -T values TZ
+#compdef -value-TZ
 
 local expl
 
diff -ur -r ../oz/Completion/X/Type/_x_display ./Completion/X/Type/_x_display
--- ../oz/Completion/X/Type/_x_display	Sun Mar 10 12:52:38 2002
+++ ./Completion/X/Type/_x_display	Sun Mar 10 13:24:35 2002
@@ -1,3 +1,3 @@
-#compdef -T values DISPLAY
+#compdef -value-DISPLAY
 
 _tags displays && _hosts -S ':0 ' -r :
diff -ur -r ../oz/Completion/Zsh/Command/_compdef ./Completion/Zsh/Command/_compdef
--- ../oz/Completion/Zsh/Command/_compdef	Sun Mar 10 12:52:38 2002
+++ ./Completion/Zsh/Command/_compdef	Sun Mar 10 16:34:55 2002
@@ -1,24 +1,37 @@
 #compdef compdef
 
-local state line expl list disp curcontext="$curcontext"
+local state line expl list disp curcontext="$curcontext" pat normal ret=1
+local args1 args2
 typeset -A opt_args
 
-_arguments -C -s -A "-*" -S \
-  '(-d)-a[make function autoloadable]' \
-  '(-d -p -P)-n[leave existing definitions intact]' \
-  "*-T[select type of completion function]:completion function type:($_comp_assocs)" \
+args2=()
+if (( ! ${words[2,-1][(I)[^-]*]} || ${words[(I)-[kK]]} )); then
+  args1=(
+    -A '-*'
+    '(-d)-a[make function autoloadable]'
+    '(-d)-n[leave existing definitions intact]'
+  )
+  args2=(
+     - d
+      '(-a -n)-d[delete]:*:completed command:->ccom'
+     - k
+      '-k[define widget and key binding]:completion function:->cfun:style:->style:*:key'
+     - K
+      '-K[define multiple widgets based on function]:*::: :->multi'
+  )
+else
+  args1=(
+    '-N[completion for named command]'
+  )
+fi
+
+_arguments -C -s -S \
+  "$args1[@]" \
+  '-p[completion for command matching pattern]' \
+  '-P[completion for command matching pattern]' \
   ':completion function:->cfun' \
-  '*:commands: _command_names' \
- - d \
-  '(-a -n)-d[delete]:*:completed command:->ccom' \
- - p \
-  '(-n)-p[completion for command matching pattern]:completion function:->cfun:pattern' \
- - P \
-  '(-n)-P[as -p for commands without own completion]:completion function:->cfun:pattern' \
- - k \
-  '-k[define widget and key binding]:completion function:->cfun:style:->style:*:key' \
- - K \
-  '-K[define multiple widgets based on function]:*::: :->multi' && return 0
+  '*:commands:->com' \
+  "$args2[@]" && return 0
 
 if [[ $state = multi ]]; then
   case $(( CURRENT % 3 )) in
@@ -30,6 +43,15 @@
 fi
 
 case $state in
+  com)
+    pat="${words[(I)-[pP]]}"
+    normal="${words[(I)-N]}"
+    if (( pat && pat > normal )); then
+      _message -e patterns 'pattern'
+    else
+      _command_names
+    fi
+  ;;
   ccom)
     _wanted commands expl 'completed command' compadd -k _comps
   ;;
diff -ur -r ../oz/Completion/Zsh/Context/_in_vared ./Completion/Zsh/Context/_in_vared
--- ../oz/Completion/Zsh/Context/_in_vared	Sun Mar 10 12:52:38 2002
+++ ./Completion/Zsh/Context/_in_vared	Sun Mar 10 13:35:24 2002
@@ -32,4 +32,4 @@
 
 compstate[insert]="${compstate[insert]//tab /}"
 
-_dispatch comps "$also"
+_dispatch '' "$also"
diff -ur -r ../oz/Completion/Zsh/Context/_redirect ./Completion/Zsh/Context/_redirect
--- ../oz/Completion/Zsh/Context/_redirect	Sun Mar 10 12:52:38 2002
+++ ./Completion/Zsh/Context/_redirect	Sun Mar 10 13:33:46 2002
@@ -7,11 +7,12 @@
 
 _set_command
 
-strs=( "$compstate[redirect]" )
+strs=( "${compstate[redirect]:s/:/-/}" )
 
 if [[ -n "$_comp_command1" ]]; then
-  strs=( "${_comp_command1}:$strs[-1]" "$strs[@]" )
-  [[ -n "$_comp_command2" ]] && strs=( "${_comp_command2}:$strs[1]" "$strs[@]" )
+  strs=( "${_comp_command1}-$strs[-1]" "$strs[@]" )
+  [[ -n "$_comp_command2" ]] && strs=( "${_comp_command2}-$strs[-1]"
+                                       "$strs[@]" )
 fi
 
-_dispatch -d redirs "$strs[@]"
+_dispatch -d -redirect- "$strs[@]"
diff -ur -r ../oz/Completion/Zsh/Context/_subscript ./Completion/Zsh/Context/_subscript
--- ../oz/Completion/Zsh/Context/_subscript	Sun Mar 10 12:52:38 2002
+++ ./Completion/Zsh/Context/_subscript	Sun Mar 10 13:36:13 2002
@@ -113,5 +113,5 @@
 
   return 1
 else
-  _dispatch comps -math-
+  _dispatch '' -math-
 fi
diff -ur -r ../oz/Completion/Zsh/Context/_value ./Completion/Zsh/Context/_value
--- ../oz/Completion/Zsh/Context/_value	Sun Mar 10 12:52:38 2002
+++ ./Completion/Zsh/Context/_value	Sun Mar 10 14:06:41 2002
@@ -1,4 +1,4 @@
-#compdef -value- -array-value- -T values -default-
+#compdef -value- -array-value- -value--default-
 
 # You can customize completion for different parameters by writing
 # functions with the tag-line `#compdef -T value <name>'.
@@ -6,7 +6,7 @@
 # and `<param-name>'. If the line contains a command (as in `make foo=<TAB>')
 # the string `<command>:<param-name>:<param-type>' is also searched for.
 
-if [[ "$service" != -default- ]]; then
+if [[ "$service" != -value-?* ]]; then
   local strs type
 
   type="${(Pt)compstate[parameter]}"
@@ -21,15 +21,15 @@
     fi
   fi
 
-  strs=( "${compstate[parameter]}:$type" "$compstate[parameter]" )
+  strs=( "${compstate[parameter]}-$type" "$compstate[parameter]" )
 
   if [[ "$compstate[context]" != *value && -n "$_comp_command1" ]]; then
-    strs=( "${_comp_command1}:$^strs[@]" "$strs[@]" )
+    strs=( "${_comp_command1}-$^strs[@]" "$strs[@]" )
     [[ -n "$_comp_command2" ]] &&
-        strs=( "${_comp_command2}:${(@)^strs[-2,-1]}" "$strs[@]" )
+        strs=( "${_comp_command2}-${(@)^strs[-2,-1]}" "$strs[@]" )
   fi
 
-  _dispatch -d values "$strs[@]"
+  _dispatch -d -value- "$strs[@]"
 else
   if [[ "$compstate[parameter]" != *-* &&
         "$compstate[context]" = *value &&
diff -ur -r ../oz/Completion/compdump ./Completion/compdump
--- ../oz/Completion/compdump	Sun Mar 10 12:52:38 2002
+++ ./Completion/compdump	Sun Mar 10 13:19:07 2002
@@ -35,43 +35,34 @@
 
 print "#files: $#_d_files" > $_d_file
 
-# First dump the arrays _comps, _servicecomps and _patcomps.  The quoting
+# Dump the arrays _comps, _services and _patcomps.  The quoting
 # hieroglyphics ensure that a single quote inside a variable is itself
 # correctly quoted.
 
-for _d_name in $_comp_assocs; do
-
-  print "\n\ntypeset -gA _$_d_name _service$_d_name _pat$_d_name _postpat$_d_name"
-
-  _d_tmp="_${_d_name}"
-  print "\n_${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
-
-  _d_tmp="_service${_d_name}"
-  print "\n_service${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
+print "\n_comps=(" >> $_d_file
+for _d_f in ${(ok)_comps}; do
+  print -r - "${(q)_d_f}" "${(q)_comps[$_d_f]}"
+done >> $_d_file
+print ")" >> $_d_file
 
-  _d_tmp="_pat${_d_name}"
-  print "\n_pat${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
+print "\n_services=(" >> $_d_file
+for _d_f in ${(ok)_services}; do
+  print -r - "${(q)_d_f}" "${(q)_services[$_d_f]}"
+done >> $_d_file
+print ")" >> $_d_file
 
-  _d_tmp="_postpat${_d_name}"
-  print "\n_postpat${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
+print "\n_patcomps=(" >> $_d_file
+for _d_f in ${(ok)_patcomps}; do
+  print -r - "${(q)_d_f}" "${(q)_patcomps[$_d_f]}"
+done >> $_d_file
+print ")" >> $_d_file
 
+_d_tmp="_postpatcomps"
+print "\n_postpatcomps=(" >> $_d_file
+for _d_f in ${(ok)_postpatcomps}; do
+  print -r - "${(q)_d_f}" "${(q)_postpatcomps[$_d_f]}"
 done >> $_d_file
+print ")" >> $_d_file
 
 print "\n_compautos=(" >> $_d_file
 for _d_f in "${(ok@)_compautos}"; do
diff -ur -r ../oz/Completion/compinit ./Completion/compinit
--- ../oz/Completion/compinit	Sun Mar 10 12:52:38 2002
+++ ./Completion/compinit	Sun Mar 10 15:03:18 2002
@@ -102,21 +102,10 @@
   esac
 done
 
-# The name suffixes for the associative arrays containing the functions
-# to call.
-
-typeset -gUa _comp_assocs
-
-_comp_assocs=(comps)
-
 # The associative arrays containing the definitions for the commands and
 # services.
-# Definitions for patterns will be stored in the associations `_pat*'
-# and `_postpat*'.
-# The assocs for the other function types are created automatically by
-# compdef.
 
-typeset -gA _comps _servicecomps _patcomps _postpatcomps
+typeset -gA _comps _services _patcomps _postpatcomps
 
 # `_compautos' contains the names and options for autoloaded functions
 # that get options.
@@ -191,9 +180,6 @@
 # The option `-P' is like `-p', but the function will be called after
 # trying to find a function defined for the command on the line if no
 # such function could be found.
-# In each of these cases the argument list may also contain `-T assoc'
-# options to specify the associactive arrays to which the following
-# definitions should be added.
 # With the `-k' option a function for a special completion keys is 
 # defined and immediately bound to those keys. Here, the extra arguments
 # are the name of one of the builtin completion widgets and any number
@@ -209,8 +195,7 @@
 # whose names are given as arguments. If combined with the `-p' option
 # it deletes the definitions for the patterns given as argument.
 # The `-d' option may not be combined with the `-k' option, i.e.
-# definitions for key function can not be removed. But one `-T assoc'
-# option may follow the `-d' to say which definitions should be removed.
+# definitions for key function can not be removed.
 #
 # Examples:
 #
@@ -232,7 +217,7 @@
 #   delete the definitions for the command names `bar' and `baz'
 
 compdef() {
-  local opt autol type func delete new i ret=0 cmd svc assoc=comps
+  local opt autol type func delete new i ret=0 cmd svc
 
   # Get the options.
 
@@ -277,38 +262,26 @@
 
     if [[ "$1" = *\=* ]]; then
       while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
-        else
-          if [[ "$1" = *\=* ]]; then
-	    cmd="${1%%\=*}"
-	    svc="${1#*\=}"
-            func="$_comps[${(e):-\${(k)_service${assoc}[(R)$svc]:-$svc}}]"
-            [[ -n ${(e):-\$_service${assoc}[$svc]} ]] &&
-                svc=${(e):-\$_service${assoc}[$svc]}
-	    [[ -z "$func" ]] &&
-	        func="${${(e):-\$_pat${assoc}[(K)$svc][1]}:-${(e):-\$_postpat${assoc}[(K)$svc][1]}}"
-            if [[ -n "$func" ]]; then
-	      eval "_${assoc}"'[$cmd]="$func"'
-	      eval "_service${assoc}"'[$cmd]="$svc"'
-	    else
-	      echo "$0: unknown command or service: $svc"
-	      ret=1
-	    fi
+        if [[ "$1" = *\=* ]]; then
+	  cmd="${1%%\=*}"
+	  svc="${1#*\=}"
+          func="$_comps[${_services[(R)$svc]:-$svc}]"
+          [[ -n ${_services[$svc]} ]] &&
+              svc=${_services[$svc]}
+	  [[ -z "$func" ]] &&
+	      func="${${_patcomps[(K)$svc][1]}:-${_postpatcomps[(K)$svc][1]}}"
+          if [[ -n "$func" ]]; then
+	    _comps[$cmd]="$func"
+	    _services[$cmd]="$svc"
 	  else
-	    echo "$0: invalid argument: $1"
+	    echo "$0: unknown command or service: $svc"
 	    ret=1
 	  fi
-          shift
-        fi
+	else
+	  echo "$0: invalid argument: $1"
+	  ret=1
+	fi
+        shift
       done
 
       return ret
@@ -322,42 +295,6 @@
     shift
 
     case "$type" in
-    pattern)
-      while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
-        else
-          eval "_pat${assoc}"'[$1]="$func"'
-          shift
-        fi
-      done
-      ;;
-    postpattern)
-      while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
-        else
-          eval "_postpat${assoc}"'[$1]="$func"'
-          shift
-        fi
-      done
-      ;;
     widgetkey)
       while [[ -n $1 ]]; do
 	if [[ $# -lt 3 ]]; then
@@ -406,54 +343,48 @@
       # For commands store the function name in the
       # associative array, command names as keys.
       while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
+        if [[ "$1" = -N ]]; then
+          type=normal
+        elif [[ "$1" = -p ]]; then
+          type=pattern
+        elif [[ "$1" = -P ]]; then
+          type=postpattern
         else
-          if [[ "$1" = *\=* ]]; then
-	    cmd="${1%%\=*}"
-	    svc=yes
-          else
-	    cmd="$1"
-	    svc=
-          fi
-          if [[ -z "$new" || -z "${(e):-\$_${assoc}[$1]}" ]]; then
-            eval "_${assoc}"'[$cmd]="$func"'
-	    [[ -n "$svc" ]] && eval "_service${assoc}"'[$cmd]="${1#*\=}"'
-	  fi
-          shift
+          case "$type" in
+          pattern)
+            _patcomps[$1]="$func"
+            ;;
+          postpattern)
+            _postpatcomps[$1]="$func"
+            ;;
+          *)
+            if [[ "$1" = *\=* ]]; then
+	      cmd="${1%%\=*}"
+	      svc=yes
+            else
+	      cmd="$1"
+	      svc=
+            fi
+            if [[ -z "$new" || -z "${_comps[$1]}" ]]; then
+              _comps[$cmd]="$func"
+	      [[ -n "$svc" ]] && _services[$cmd]="${1#*\=}"
+	    fi
+            ;;
+          esac
         fi
+        shift
       done
       ;;
     esac
   else
     # Handle the `-d' option, deleting.
 
-    if [[ $1 = -T ]]; then
-      shift
-      if (( ! $# )); then
-        echo "$0: missing type"
-        return 1
-      fi
-      _comp_assocs=( "$_comp_assocs[@]" "$1" )
-      typeset -gA _$1 _service$1 _pat$1 _postpat$1
-      assoc="$1"
-      shift
-    fi
-
     case "$type" in
     pattern)
-      unset "_pat${assoc}[$^@]"
+      unset "_patcomps[$^@]"
       ;;
     postpattern)
-      unset "_postpat${assoc}[$^@]"
+      unset "_postpatcomps[$^@]"
       ;;
     key)
       # Oops, cannot do that yet.
@@ -462,7 +393,7 @@
       return 1
       ;;
     *)
-      unset "_${assoc}[$^@]"
+      unset "_comps[$^@]"
     esac
   fi
 }
diff -ur -r ../oz/Doc/Zsh/compsys.yo ./Doc/Zsh/compsys.yo
--- ../oz/Doc/Zsh/compsys.yo	Sun Mar 10 12:52:38 2002
+++ ./Doc/Zsh/compsys.yo	Sun Mar 10 15:21:30 2002
@@ -159,7 +159,8 @@
 The tags are:
 
 startitem()
-item(tt(#compdef) var(names...))(
+item(tt(#compdef) var(names...) [ tt(-[pP]) var(patterns...) [ tt(-N)
+var(names...) ] ])(
 The file will be made autoloadable and the function defined 
 in it will be called when completing var(names), each of which is
 either the name of a command whose arguments are to be completed or one of
@@ -174,33 +175,18 @@
 to the string `tt(service)'.  The function can then use that parameter 
 to decide what to complete.
 
-Finally, the list of var(names) may contain tt(-T) options, each
-followed by a type name.  These type names describe in which set of
-completion function definitions the function is to be stored.  The
-default without a tt(-T) option is `tt(comps)', saying that the
-function is a normal completion function.  Other type names currently
-understood by the completion system are tt(redirs) and tt(values).
-The first is used to define specialised completion functions for
-use after redirection operators for certain commands and the latter is
-used to define functions used when completing values of parameters.
-For example, to define the function that should be used when
-completing after `tt(foo=<TAB>)' one would use the tag line:
-
-example(#compdef -T values foo)
-
-When the function is called, the parameter tt($comptype) will be set
-to the type name, making it easy to distinguish what should be
-completed.
-)
-item(tt(#compdef -p) var(patterns...))(
-The file will be made autoloadable and the function defined in it will be
-called when completing for a command whose name matches the given
-var(pattern) (a standard globbing pattern).  As in the first case, the
-list of var(patterns) may contain tt(-T) options.
-)
-item(tt(#compdef -P) var(patterns...))(
-Like the previous one, but the function will be called only if no
-completion function for the command on the line could be found.
+If the list of var(names) contains a tt(-p) or tt(-P) option, the
+following words are taken to be patterns.  When completing for a
+command or context whose name matches one of the patterns, the
+function will be called.  In the case of tt(-P), this will only be
+done if no other completion function for the command or context could
+be found (i.e. this can be used to define default completion for
+commands or contexts matching one of the patterns which don't have a
+completion function specifically defined for them).
+
+If the list contains the tt(-N) option, the following words are used
+as in the normal case again.  Another tt(-p) or tt(-P) option can be
+usedto toggle back to defining patterns again. 
 )
 item(tt(#compdef -k) var(style key-sequences...))(
 This can be used to bind special completion functions to the
@@ -272,10 +258,8 @@
 findex(compdef)
 cindex(completion system, adding definitions)
 startitem()
-xitem(tt(compdef) [ tt(-an) ] var(function names) [ tt(-T) var(type) ] ...))
-xitem(tt(compdef -d) [ tt(-T) var(type) ] var(names...))
-xitem(tt(compdef -p) [ tt(-a) ] var(function patterns) [ tt(-T) var(type) ] ...)
-xitem(tt(compdef -P) [ tt(-a) ] var(function patterns) [ tt(-T) var(type) ] ...)
+xitem(tt(compdef) [ tt(-an) ] var(function names...) [ tt(-[pP]) var(patterns...) ])
+xitem(tt(compdef -d) var(names...))
 xitem(tt(compdef -k) [ tt(-an) ] var(function style key-sequences...))
 item(tt(compdef -K) [ tt(-an) ] var(function name style key-sequences ...))(
 The first form tells the completion system to call the given
@@ -297,27 +281,25 @@
 
 example(compdef '_files -g "*.h"' foo)
 
-The tt(-T) options in the list of var(names) define for which type of
-completions the function is to be used, i.e. in which set of
-completion functions definitions it should be added.  Currently used
-tt(type)s are tt(comps) (the default, for normal completion functions
-for command completion), tt(values) for completion of parameter values
-in assignments and tt(redirs) for completion after redirection
-operators.
-
 If the
 tt(-n) option is given, any existing completion behaviour for particular
 contexts or commands will not be altered.  These definitions can be deleted
 by giving the tt(-d) option as in the second form.
 
-The form with tt(-p) is similar to the first, but var(function) will be
-called for all commands whose name matches the var(pattern); this is like
-the tt(#compdef -p) function tag.
-
-The form with tt(-P) is like the third, but the var(function) will be
-called only if no function for the command itself was found or if one
-was found and it set the tt(_compskip) parameter to a value em(not)
-containing the substring tt(patterns).
+In both of the first two cases forms and as for the tt(#compdef) tag
+described above, the var(names) may also contain tt(-p), tt(-P) and
+tt(-N) options.  The first two make the following arguments be used as
+patterns and the var(function) will be called for all commands and
+contexts matching one of the patterns.  Wtih tt(-P) this will only
+happen if no specific function is defined for the command or context.
+The tt(-N) option toggles back to using the var(names) as described
+above.
+
+Inside functions defined for patterns, the parameter tt($_compskip)
+may be used.  If it is set to a value containing the substring
+`tt(patterns)' none of the pattern-functions will be called.  If it is
+set to a value containing the substring `tt(all)', no other function
+will be called.
 
 The form with tt(-k) defines a widget with the same name as the var(function)
 which will be called for each of the var(key-sequences); this is like the
@@ -2566,6 +2548,25 @@
 (e.g. completion for the `tt(-tilde-)' context is done by the function 
 named `tt(_tilde)').
 
+The functions for some contexts re-dispatch by calling the function
+tt(_dispatch) with more specific information.  Currently this is done
+for the contexts tt(-value-)/tt(-array-value-) and tt(-redirect-).
+Functions for completing parameter values are searched for by using
+`tt(-value-)var(name)tt(-)var(type)', `tt(-value-)var(name)' and, for
+cases like `tt(make LDFLAGS=<TAB>)' also
+`tt(-value-)var(command)tt(-)var(name)tt(-)var(type)' and
+`tt(-value-)var(command)tt(-)var(name)'.  Functions for completing
+redirections are searched for using
+`tt(-redirect-)var(command)tt(-)var(operator)' and
+`tt(-redirect-)var(operator)'.
+
+For example:
+
+example(compdef '_files -g "*.log"' '-redirect-2>')
+
+could be used to complete files matching `tt(*.log)' when completing
+after `tt(foo 2> <TAB>)'.
+
 Before trying to find a function for a specific context, tt(_complete) 
 checks if the parameter `tt(compcontext)' is set.  If it is set to an
 array, the elements are taken to be the possible matches which will be
@@ -3657,17 +3658,17 @@
 passed down to the builtins which implement the internals of completion.
 )
 findex(_dispatch)
-item(tt(_dispatch) [ tt(-d) ] var(type strings ...))(
-This function looks up the function defined for the first var(string)
-in the set of definitions named var(type) (these are those definitions
-defined with `tt(-T )var(type)').  If one is found, it is called to
-generate completions.  Otherwise the definition for the second
-var(string) is looked up and so on.  If none is found and the tt(-d)
-option is given, the definition for the special name tt(-default-) is
-used.
-
-This function is the one responsible for setting the parameters
-tt($service) and tt($comptype).
+item(tt(_dispatch) [ tt(-d) ] var(prefix strings ...))(
+This looks up the functions defined for the var(strings) (prefixed
+with var(prefix)) one after another until it finds one that is
+defined. That function is then called to generate the matches.  If no
+function is found and the tt(-d) option is given, the definition for
+either the special names var(prefix)tt(-default-) or tt(-default-) is
+used, if defined.
+
+This function is the one responsible for setting the parameter
+tt($service) and for setting the var(context/command) field of the
+tt($curcontext) parameter.
 )
 findex(_files)
 item(tt(_files))(

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Sven Wischnowsky]

I wrote:

> ...
> 
> I'm not going to commit this patch before I get replies, but I like
> it.  A lot.  Because it makes things easier without losing power.
> One thing we could think about is a standard for offering more
> information in the context name.  I used parts separated by hyphens
> becuase that's what we used before for sub-commands, but maybe there's
> a better way or more places where we can offer more information.

I forgot to say: somehow I think the way this is handled now is
connected to the problem with default completions.  My thoughts are
very fuzzy, though.  For values and redirections we now have a (what I
consider) clean way to give default completions.  I know that the
my-accounts thing is on a different level, but does it have to be?

Does anyone have the same feeling?  Any ideas?


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Peter Stephenson]

Sven Wischnowsky wrote:
> So, I wrote the patch below.  Removing the -T stuff and consistently
> using names like `-value-foo' or `-redirect-echo-2>' everywhere, both
> for the context used for styles and for compdef/#compdef (that's why
> we don't need separated sets of completion functions anymore).

This makes a lot of sense.  I haven't quite understood how this system
handles the difference between `-redirect-2>' and `-redirect-echo-2>'.
Suppose I defined a redirection for the former, will I still get a
context including `-redirect-echo-2>'?  And is that the same for a plain
`-redirect-'?  I would guess yes, since the context depends on what you
are completing rather than what function is doing it (and patterns are a
more natural part of styles than of compdef definitions).

The only worry is that someone, somewhere will decide it's a great idea
to have commands beginning with `-' for some special use.  I don't see
how we can guard against that in general, though.  We can't make the
current set of completion functions indendent of the choice of
character.  We may just as well stick with -.  Maybe we could allow it
to be escaped, like `:' (often) can be.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Redirection completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > So, I wrote the patch below.  Removing the -T stuff and consistently
> > using names like `-value-foo' or `-redirect-echo-2>' everywhere, both
> > for the context used for styles and for compdef/#compdef (that's why
> > we don't need separated sets of completion functions anymore).
> 
> This makes a lot of sense.

Good.

>  I haven't quite understood how this system
> handles the difference between `-redirect-2>' and `-redirect-echo-2>'.
> Suppose I defined a redirection for the former, will I still get a
> context including `-redirect-echo-2>'?  And is that the same for a plain
> `-redirect-'?  I would guess yes, since the context depends on what you
> are completing rather than what function is doing it (and patterns are a
> more natural part of styles than of compdef definitions).

The functions calling _dispatch give it a bunch of string that are to
be looked up in order until one with a defined function is found.
And, in this case, _redirect makes sure to give first `-redirect-echo-2>', 
then `-redirect-2>'.  So you can define a special version for echo and
another one for completion after `2>' everywhere else.  _dispatch adds
to this the context `-default-' preceded by the prefix it was given,
so default redirection completion is defined by `-redirect--default-',
which is what is now in _files.

_redirect itself is still in charge of the context -redirect- itself.

> The only worry is that someone, somewhere will decide it's a great idea
> to have commands beginning with `-' for some special use.  I don't see
> how we can guard against that in general, though.  We can't make the
> current set of completion functions indendent of the choice of
> character.  We may just as well stick with -.  Maybe we could allow it
> to be escaped, like `:' (often) can be.

Hm, yes, although having to quote a hyphen looks weird.  I would have
suggested usin `|' if that weren't a pattern matching character.
Safer would be `;' but that looks too much like a colon for my taste.
Maybe use a comma?


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Peter Stephenson]

Sven Wischnowsky wrote:
> The functions calling _dispatch give it a bunch of string that are to
> be looked up in order until one with a defined function is found.
> And, in this case, _redirect makes sure to give first `-redirect-echo-2>', 
> then `-redirect-2>'.  So you can define a special version for echo and
> another one for completion after `2>' everywhere else.  _dispatch adds
> to this the context `-default-' preceded by the prefix it was given,
> so default redirection completion is defined by `-redirect--default-',
> which is what is now in _files.

Sorry, I didn't make my question clear.  I understand how it looks for
what to execute to find completions (though I wouldn't have guessed
about `-redirect--default-' without looking at the code, although that's
logical).  My question was, when I get where I'm going and try
completion, what context is seen by styles?  What I'm worring about is
if I'm in some generic form of redirection completion I can still check
for `-redirect-echo-2>' in pattern-files, or does the context still just look
like `-redirect-2>' or `-redirect--default-'?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Redirection completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> Sorry, I didn't make my question clear.  I understand how it looks for
> what to execute to find completions (though I wouldn't have guessed
> about `-redirect--default-' without looking at the code, although that's
> logical).  My question was, when I get where I'm going and try
> completion, what context is seen by styles?  What I'm worring about is
> if I'm in some generic form of redirection completion I can still check
> for `-redirect-echo-2>' in pattern-files, or does the context still just look
> like `-redirect-2>' or `-redirect--default-'?

Ah, I see.  Currently it is as you fear, it just uses the string for
which it found a completion function.  That's obviously silly and I'll
change that this evening.

But I'm not really sure which string to prefer in each case.  I'd
prefer the most specific one, i.e. `-redirect-echo-2>' in this case.
Would that be ok for our users if we document it?


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Peter Stephenson]

Sven Wischnowsky wrote:
> What I'm worring about is
> > if I'm in some generic form of redirection completion I can still check
> > for `-redirect-echo-2>' in pattern-files, or does the context still just lo
> ok
> > like `-redirect-2>' or `-redirect--default-'?
> 
> Ah, I see.  Currently it is as you fear, it just uses the string for
> which it found a completion function.  That's obviously silly and I'll
> change that this evening.
> 
> But I'm not really sure which string to prefer in each case.  I'd
> prefer the most specific one, i.e. `-redirect-echo-2>' in this case.
> Would that be ok for our users if we document it?

I think that would be fine.  As my slightly compressed first email was
supposed to indicate, I think it's entirely natural in a zstyle command
to stick in `*'s where you don't care about the result (or [^:]# if
you're really paranoid).  I suspect people are perfectly used to this.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Redirection completion

[Bart Schaefer]

On Mar 11,  1:08pm, Sven Wischnowsky wrote:
} 
} Peter Stephenson wrote:
} 
} > if I'm in some generic form of redirection completion I can still check
} > for `-redirect-echo-2>' in pattern-files, or does the context still just
} > look like `-redirect-2>' or `-redirect--default-'?
} 
} But I'm not really sure which string to prefer in each case.  I'd
} prefer the most specific one, i.e. `-redirect-echo-2>' in this case.
} Would that be ok for our users if we document it?

I think using the most-specific is fine, but I'd like to request a change
in the format.

Firstly I'd like to keep the "flavor" of redirection tightly associated
with the word `redirect', i.e. rather than

	-redirect-echo-2>

It should be

	-redirect-2>-echo

Then, I think, it would not be necessary to try each of `-redirect-',
`-redirect-2>', and `-redirect-2>-echo' in turn, because styles could be
written easily with wildcards e.g. `-redirect-*' or `-redirect-2>*'.

Unless I'm missing something about why all three are tried?

This points up the second change I'd like to request:  Make this style
fragment work the same way that styles in general work, e.g., define a
fixed set of delimiter-separated segments and have them always be there
even if sometimes empty.  E.g. supposing we switched to comma as the
delimiter, as Sven tossed out in one of the earlier messages on this
thread, the context would look like `-redirect-,2>,echo' and if for some
reason the command name were not known it would be `-redirect-,2>,'.

I suppose strictly speaking the first of those commas could be omitted
because we must always know what redirection operator we're dealing with
(else we wouldn't be in -redirect- context at all), e.g. `-redirect-2>,'.

Random additional comments:

If we do stick with hyphens, what does the context look like in the case
of completion after:

zsh% - 2>

(It's perfectly legal syntax to put the redirection anywhere on the line,
even before the command for which the precommand modifier is intended.)
If we instead switch to commas, what do we do in case of a command named
`,'? (I knew people in grad school who used a csh script named that, for
reasons too obscure to go into).  On a similar note, do we need to fix
somehow the existing contexts for completing after the `:' command?

Different tack:  If I have

zsh% ls >

with the cursor positioned ON the `>', what context(s) get tried when I
press TAB?  I might expect it to complete file descriptor numbers ...
and in that case, I'd want to complete only the numbers of *valid* file
descriptors, but those aren't available to shell functions (yet).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Redirection completion

[Sven Wischnowsky]

[I'm withholding the patch for now...]

Many questions from Bart:

> ...
> 
> Firstly I'd like to keep the "flavor" of redirection tightly associated
> with the word `redirect', i.e. rather than
> 
> 	-redirect-echo-2>
> 
> It should be
> 
> 	-redirect-2>-echo

That's ok, I think.  What do you suggest for values, then?
`-value-<name>-<type>-<command>'?  <name> is the parameter name,
<type> is scalar/array/... and <command> is only set when completing
after something like `make FOO=<TAB>'.  That, by the way, is the
reason why I put the command directly after the `-value-' or
`-redirect-': it can be there in both cases.

> Then, I think, it would not be necessary to try each of `-redirect-',
> `-redirect-2>', and `-redirect-2>-echo' in turn, because styles could be
> written easily with wildcards e.g. `-redirect-*' or `-redirect-2>*'.
> 
> Unless I'm missing something about why all three are tried?

Yes.  The main reason for this is that I want it to be easy to define
functions (not styles) for types of redirections or for parameters
without having to use `compdef -[pP]' everywhere.

> This points up the second change I'd like to request:  Make this style
> fragment work the same way that styles in general work, e.g., define a
> fixed set of delimiter-separated segments and have them always be there
> even if sometimes empty.  E.g. supposing we switched to comma as the
> delimiter, as Sven tossed out in one of the earlier messages on this
> thread, the context would look like `-redirect-,2>,echo' and if for some
> reason the command name were not known it would be `-redirect-,2>,'.

I've actually been thinking the same (before that idea with the
comma).  I'd prefer a solution where the different can have at least
almost the same meaning in every case, though (i.e. values and
parameters for now).  Just as we did with full context names.

> I suppose strictly speaking the first of those commas could be omitted
> because we must always know what redirection operator we're dealing with
> (else we wouldn't be in -redirect- context at all), e.g. `-redirect-2>,'.

If we go this way, I'd be in favour of putting it there -- it might
also make the description in the docs easier (`some functions
redispatch and modify the context name to show this, leaving the base
name of the command/context field and appending to it the more precise
description, separated by commas').

> Random additional comments:
> 
> If we do stick with hyphens, what does the context look like in the case
> of completion after:
> 
> zsh% - 2>
> 
> (It's perfectly legal syntax to put the redirection anywhere on the line,
> even before the command for which the precommand modifier is intended.)

Since completion for redirection is determined on the same lave as
_precommand would be found, you should (haven't tried) currently get
`-' in the command part.  Hrm, that's ugly, obviously, because you
would get the same for `- foo > <TAB>'.  We've got to thnk some more
about this...

> If we instead switch to commas, what do we do in case of a command named
> `,'? (I knew people in grad school who used a csh script named that, for
> reasons too obscure to go into).  On a similar note, do we need to fix
> somehow the existing contexts for completing after the `:' command?

Hrm.  We could quote the separation character if it appears inside the
command name.

> Different tack:  If I have
> 
> zsh% ls >
> 
> with the cursor positioned ON the `>', what context(s) get tried when I
> press TAB?  I might expect it to complete file descriptor numbers ...
> and in that case, I'd want to complete only the numbers of *valid* file
> descriptors, but those aren't available to shell functions (yet).

Yes that would be nice.

Currently you should get argument completion (but strangely, trying
`echo ><TAB>' shows that `-command-' is tried, only after `echo foo ><TBA>'
do we get argument completion -- I'll have to have a look).


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Oliver Kiddle]

Sven wrote:

> Whew.  Thinking some more lead to the patch below which is probably
> entirely different from what everyone expected.  It removes the -T
> completion type handling again.  Ahem.  Let me explain.

This is better. Certainly, it wasn't what I was expecting though I was
thinking that it was unfortunate that we were inconsistent with words we
were using (redirs vs. -redirect- etc). After more thought I was also
further convinced about using the command part of the context to
describe the dispatch key.

I've tried yesterdays patch and things don't seem to be quite working
yet - I'm just getting file completion. I also had limited success with
pattern completions for values and the old -T system. I've put one at
the end. If you fix it, please commit it yourself. I perhaps just
needed those new -p and -N changes which I was going to suggest.

I also got _gzip to handle GZIP which I'll post once you've got this
latest change done and I've fixed it not to use -T. The compset -q and
faking $words[0] made me wonder that it wouldn't be a good idea to have
an option to compset to fake $words[0] as well. I think we do it in
quite a few other places.

Quoting Sven replying to me in 16752 (1st March):
> > Only I just wonder now: if we have to triplicate the list of commands
> > just to handle redirections (normal, < and >) it might end up being a
> > bit tedious.
> 
> I fear I don't understand this. We don't have to change anything
> unless we want to be able to offer new features (and if anything
> doesn't work this way it's a bug and I'd like to hear about it).

My worry was that if, for example in _gzip we wanted to handle all the
redirections we will need something like:

#compdef gzip gunzip gzcat -redirect->-gzip -redirect-<-gzip
-redirect-2>-gzip -redirect-<-gunzip -redirect->-gunzip
-redirect-2>gunzip -redirect-<-gzcat -redirect->-gzcat
-redirect-2>-gzcat -value-GZIP

so we either now use pattern completions a lot or allow
compdef {,-redirect-{<,>,2>}}-{gzip,gzcat,gunzip}

or have I misunderstood something somewhere?

also note that the above perhaps further backs up Bart's very good
point about keeping the redirection operator next to -redirect-.

Sven wrote:
> I forgot to say: somehow I think the way this is handled now is
> connected to the problem with default completions.  My thoughts are
> very fuzzy, though.

I've failed to spot the connection with default completions. Can you
summarise the issues perhaps?

On other points: a comma seems best as the separator though I'm not
particularly fussed. Quoting is probably the best solution to commands
with the separator in their name. Using a hyphen may be confusing
because it might cause problems if the trailing - of -redirect- can be
the separator as well as part of the context name.

Sven wrote:
> 
> That's ok, I think.  What do you suggest for values, then?
> `-value-<name>-<type>-<command>'?  <name> is the parameter name,
> <type> is scalar/array/... and <command> is only set when completing
> after something like `make FOO=<TAB>'.  That, by the way, is the
> reason why I put the command directly after the `-value-' or
> `-redirect-': it can be there in both cases.

Note that the old system allowed a completion function for a specific
association index though admittedly, we never used it.

By <type>, do you mean the full ${(t)name}? Useful I suppose but we're
going to get long contexts. This squashing everything we might want into
a string is starting to get silly.

Keeping the command always at the end is a good idea so that it is in a
consistent place (the beginning would be just as good).

It is also arguable that for normal completion, we should start with
something like -command-.

> > with the cursor positioned ON the `>', what context(s) get tried when I
> > press TAB?  I might expect it to complete file descriptor numbers ...
> > and in that case, I'd want to complete only the numbers of *valid* file
> > descriptors, but those aren't available to shell functions (yet).
> 
> Yes that would be nice.
> 
> Currently you should get argument completion (but strangely, trying
> `echo ><TAB>' shows that `-command-' is tried, only after `echo foo ><TBA>'
> do we get argument completion -- I'll have to have a look).

There are a few places where the division into contexts is not as ideal
as would be nice. Hence not being able to complete glob qualifiers,
parameter expansion flags etc as we do for subscript flags.

Oliver

#compdef -T values -P LC_* LANG

local locales

if (( $+commands[locale] )); then
  locales=( $(_call_program locales locale -a) )
else
  locales=( /usr/lib/locale/* )
fi

_wanted locales expl locale compadd "$@" -a locales -


This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: Redirection completion

[Sven Wischnowsky]

Ok, below is the next version, I'm going to commit it this time.

It uses the comma-separated sub-contexts discussed. For values it is
`-value-,<name>,<cmd>', so I've not put the parameter type in it, as
suggested by Oliver. For redirection it is `-redirect-,<op>,<cmd>'.

_value and _redirect try multiple strings of this form to allow easier
definition of defaults.  This is done by replacing parts with the
string `-default-' in the hope that this is more consistent and to be
able to distinguish this case from the case that the command name part
can't be set because there isn't a command name on the line. (Hope
this is ok, Bart?)

For example, completion after `foo=<TAB>' makes _value try:

  1) -value-,foo,
  2) -value-,foo,-default-
  3) -value-,-default-,-default-

in this order. For association-values this is also re-dispatched with
`-value-,foo-key,' (this was also done by previous patches but not so
cleanly).

Order of lookup and of the parts and use of `-default-' can be changed
if noone likes it (except me). This order is partly the result of using
brace extension in the calls to _dispatch. But it's important, affects
also redirection and the two orders are connected, I think, by the
question which of the two parts is the more important one. I.e.:
should `-redirect-,-default-,echo' or `-redirect-,>,-default-' take
precedence?

And another question where the default-handling is important is: when
should post-patterns (-P) be tried? Currently this is done only if we
would otherwise use the function defined for the least specific
context (the one with all parts being `-default-').

In the sub-context used for looking up styles it always uses the most
specific version.


Oliver Kiddle wrote:

> ...
> 
> I've tried yesterdays patch and things don't seem to be quite working
> yet - I'm just getting file completion. I also had limited success with
> pattern completions for values and the old -T system. I've put one at
> the end. If you fix it, please commit it yourself. I perhaps just
> needed those new -p and -N changes which I was going to suggest.

Can't say anything about this without more information. Have you
remembered to remove the dump-file?

> I also got _gzip to handle GZIP which I'll post once you've got this
> latest change done and I've fixed it not to use -T. The compset -q and
> faking $words[0] made me wonder that it wouldn't be a good idea to have
> an option to compset to fake $words[0] as well. I think we do it in
> quite a few other places.

A few, yes. But I don't think that we really need support from builtins
for every little peace of shell code ;-)

> ...
> 
> My worry was that if, for example in _gzip we wanted to handle all the
> redirections we will need something like:
> 
> #compdef gzip gunzip gzcat -redirect->-gzip -redirect-<-gzip
> -redirect-2>-gzip -redirect-<-gunzip -redirect->-gunzip
> -redirect-2>gunzip -redirect-<-gzcat -redirect->-gzcat
> -redirect-2>-gzcat -value-GZIP
> 
> so we either now use pattern completions a lot or allow
> compdef {,-redirect-{<,>,2>}}-{gzip,gzcat,gunzip}
> 
> or have I misunderstood something somewhere?

Aha. Ugh. No. See above, `-redirect-,-default-,gzip' etc. are enough.
Not that short either, I admit, but allowing braces there isn't *that*
simple (well, it isn't that hard either, a bit of `eval' with an array
and some quoting magic, but...).

> ..
> 
> I've failed to spot the connection with default completions. Can you
> summarise the issues perhaps?

I wished I could. It's currently more of a feeling than anything else.
I may well be on a completely wrong track, I'll try to think some more.

> On other points: a comma seems best as the separator though I'm not
> particularly fussed. Quoting is probably the best solution to commands
> with the separator in their name. Using a hyphen may be confusing
> because it might cause problems if the trailing - of -redirect- can be
> the separator as well as part of the context name.

Btw. currently none of the functions tries to do anything about
quoting any characters. And with the fixed format it probably isn't
that much of a problem, I think, especially if we keep the order of
the parts, because a comma can't appear in neither the redirection
operator nor the parameter name.

> ...
> 
> It is also arguable that for normal completion, we should start with
> something like -command-.

Yes, that thought crossed my mind, too. I quickly looked the other way.

> > > with the cursor positioned ON the `>', what context(s) get tried when I
> > > press TAB?  I might expect it to complete file descriptor numbers ...
> > > and in that case, I'd want to complete only the numbers of *valid* file
> > > descriptors, but those aren't available to shell functions (yet).
> > 
> > Yes that would be nice.
> > 
> > Currently you should get argument completion (but strangely, trying
> > `echo ><TAB>' shows that `-command-' is tried, only after `echo foo ><TBA>'
> > do we get argument completion -- I'll have to have a look).
> 
> There are a few places where the division into contexts is not as ideal
> as would be nice. Hence not being able to complete glob qualifiers,
> parameter expansion flags etc as we do for subscript flags.

About that <tab> ON the redirection operator: that was a small bug in
the C-code. It didn't insert the `x' for the empty word completion
thingy.

For what Oliver wrote: one could say that's really a problem of the
C-code not knowing any better what to report. One could also say that
somewhere near the beginning of the completion system we could look at
$BUFFER to find out if we are in a special context.

> #compdef -T values -P LC_* LANG

I've turned this into the _locales function in the patch.


Bart Schaefer wrote:

> If we do stick with hyphens, what does the context look like in the case
> of completion after:
> 
> zsh% - 2>

(See above for the quoting issue.) The problem here is of course, that
`- foo <TAB>' should report `echo' as the command but currently
doesn't. I've got some weird ideas about functions being declared to
take precedence over the normal context handling (and that may be
connected with the globbing-flag completion Oliver mentioned), but
nothing to talk about yet.


Bye
  Sven

Index: Completion/compdump
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/compdump,v
retrieving revision 1.3
diff -u -r1.3 compdump
--- Completion/compdump	4 Mar 2002 08:53:42 -0000	1.3
+++ Completion/compdump	13 Mar 2002 09:20:36 -0000
@@ -35,43 +35,34 @@
 
 print "#files: $#_d_files" > $_d_file
 
-# First dump the arrays _comps, _servicecomps and _patcomps.  The quoting
+# Dump the arrays _comps, _services and _patcomps.  The quoting
 # hieroglyphics ensure that a single quote inside a variable is itself
 # correctly quoted.
 
-for _d_name in $_comp_assocs; do
-
-  print "\n\ntypeset -gA _$_d_name _service$_d_name _pat$_d_name _postpat$_d_name"
-
-  _d_tmp="_${_d_name}"
-  print "\n_${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
-
-  _d_tmp="_service${_d_name}"
-  print "\n_service${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
+print "\n_comps=(" >> $_d_file
+for _d_f in ${(ok)_comps}; do
+  print -r - "${(q)_d_f}" "${(q)_comps[$_d_f]}"
+done >> $_d_file
+print ")" >> $_d_file
 
-  _d_tmp="_pat${_d_name}"
-  print "\n_pat${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
+print "\n_services=(" >> $_d_file
+for _d_f in ${(ok)_services}; do
+  print -r - "${(q)_d_f}" "${(q)_services[$_d_f]}"
+done >> $_d_file
+print ")" >> $_d_file
 
-  _d_tmp="_postpat${_d_name}"
-  print "\n_postpat${_d_name}=("
-  for _d_f in ${(Pok)_d_tmp}; do
-    print -r - "${(q)_d_f}" "${(q)${(e):-\$${_d_tmp}[$_d_f]}}"
-  done
-  print ")"
+print "\n_patcomps=(" >> $_d_file
+for _d_f in ${(ok)_patcomps}; do
+  print -r - "${(q)_d_f}" "${(q)_patcomps[$_d_f]}"
+done >> $_d_file
+print ")" >> $_d_file
 
+_d_tmp="_postpatcomps"
+print "\n_postpatcomps=(" >> $_d_file
+for _d_f in ${(ok)_postpatcomps}; do
+  print -r - "${(q)_d_f}" "${(q)_postpatcomps[$_d_f]}"
 done >> $_d_file
+print ")" >> $_d_file
 
 print "\n_compautos=(" >> $_d_file
 for _d_f in "${(ok@)_compautos}"; do
Index: Completion/compinit
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/compinit,v
retrieving revision 1.7
diff -u -r1.7 compinit
--- Completion/compinit	4 Mar 2002 08:53:42 -0000	1.7
+++ Completion/compinit	13 Mar 2002 09:20:36 -0000
@@ -102,21 +102,10 @@
   esac
 done
 
-# The name suffixes for the associative arrays containing the functions
-# to call.
-
-typeset -gUa _comp_assocs
-
-_comp_assocs=(comps)
-
 # The associative arrays containing the definitions for the commands and
 # services.
-# Definitions for patterns will be stored in the associations `_pat*'
-# and `_postpat*'.
-# The assocs for the other function types are created automatically by
-# compdef.
 
-typeset -gA _comps _servicecomps _patcomps _postpatcomps
+typeset -gA _comps _services _patcomps _postpatcomps
 
 # `_compautos' contains the names and options for autoloaded functions
 # that get options.
@@ -191,9 +180,6 @@
 # The option `-P' is like `-p', but the function will be called after
 # trying to find a function defined for the command on the line if no
 # such function could be found.
-# In each of these cases the argument list may also contain `-T assoc'
-# options to specify the associactive arrays to which the following
-# definitions should be added.
 # With the `-k' option a function for a special completion keys is 
 # defined and immediately bound to those keys. Here, the extra arguments
 # are the name of one of the builtin completion widgets and any number
@@ -209,8 +195,7 @@
 # whose names are given as arguments. If combined with the `-p' option
 # it deletes the definitions for the patterns given as argument.
 # The `-d' option may not be combined with the `-k' option, i.e.
-# definitions for key function can not be removed. But one `-T assoc'
-# option may follow the `-d' to say which definitions should be removed.
+# definitions for key function can not be removed.
 #
 # Examples:
 #
@@ -232,7 +217,7 @@
 #   delete the definitions for the command names `bar' and `baz'
 
 compdef() {
-  local opt autol type func delete new i ret=0 cmd svc assoc=comps
+  local opt autol type func delete new i ret=0 cmd svc
 
   # Get the options.
 
@@ -277,38 +262,26 @@
 
     if [[ "$1" = *\=* ]]; then
       while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
-        else
-          if [[ "$1" = *\=* ]]; then
-	    cmd="${1%%\=*}"
-	    svc="${1#*\=}"
-            func="$_comps[${(e):-\${(k)_service${assoc}[(R)$svc]:-$svc}}]"
-            [[ -n ${(e):-\$_service${assoc}[$svc]} ]] &&
-                svc=${(e):-\$_service${assoc}[$svc]}
-	    [[ -z "$func" ]] &&
-	        func="${${(e):-\$_pat${assoc}[(K)$svc][1]}:-${(e):-\$_postpat${assoc}[(K)$svc][1]}}"
-            if [[ -n "$func" ]]; then
-	      eval "_${assoc}"'[$cmd]="$func"'
-	      eval "_service${assoc}"'[$cmd]="$svc"'
-	    else
-	      echo "$0: unknown command or service: $svc"
-	      ret=1
-	    fi
+        if [[ "$1" = *\=* ]]; then
+	  cmd="${1%%\=*}"
+	  svc="${1#*\=}"
+          func="$_comps[${_services[(R)$svc]:-$svc}]"
+          [[ -n ${_services[$svc]} ]] &&
+              svc=${_services[$svc]}
+	  [[ -z "$func" ]] &&
+	      func="${${_patcomps[(K)$svc][1]}:-${_postpatcomps[(K)$svc][1]}}"
+          if [[ -n "$func" ]]; then
+	    _comps[$cmd]="$func"
+	    _services[$cmd]="$svc"
 	  else
-	    echo "$0: invalid argument: $1"
+	    echo "$0: unknown command or service: $svc"
 	    ret=1
 	  fi
-          shift
-        fi
+	else
+	  echo "$0: invalid argument: $1"
+	  ret=1
+	fi
+        shift
       done
 
       return ret
@@ -322,42 +295,6 @@
     shift
 
     case "$type" in
-    pattern)
-      while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
-        else
-          eval "_pat${assoc}"'[$1]="$func"'
-          shift
-        fi
-      done
-      ;;
-    postpattern)
-      while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
-        else
-          eval "_postpat${assoc}"'[$1]="$func"'
-          shift
-        fi
-      done
-      ;;
     widgetkey)
       while [[ -n $1 ]]; do
 	if [[ $# -lt 3 ]]; then
@@ -406,54 +343,48 @@
       # For commands store the function name in the
       # associative array, command names as keys.
       while (( $# )); do
-        if [[ $1 = -T ]]; then
-          shift
-          if (( ! $# )); then
-            echo "$0: missing type"
-            return 1
-          fi
-          _comp_assocs=( "$_comp_assocs[@]" "$1" )
-          typeset -gA _$1 _service$1 _pat$1 _postpat$1
-          assoc="$1"
-          shift
+        if [[ "$1" = -N ]]; then
+          type=normal
+        elif [[ "$1" = -p ]]; then
+          type=pattern
+        elif [[ "$1" = -P ]]; then
+          type=postpattern
         else
-          if [[ "$1" = *\=* ]]; then
-	    cmd="${1%%\=*}"
-	    svc=yes
-          else
-	    cmd="$1"
-	    svc=
-          fi
-          if [[ -z "$new" || -z "${(e):-\$_${assoc}[$1]}" ]]; then
-            eval "_${assoc}"'[$cmd]="$func"'
-	    [[ -n "$svc" ]] && eval "_service${assoc}"'[$cmd]="${1#*\=}"'
-	  fi
-          shift
+          case "$type" in
+          pattern)
+            _patcomps[$1]="$func"
+            ;;
+          postpattern)
+            _postpatcomps[$1]="$func"
+            ;;
+          *)
+            if [[ "$1" = *\=* ]]; then
+	      cmd="${1%%\=*}"
+	      svc=yes
+            else
+	      cmd="$1"
+	      svc=
+            fi
+            if [[ -z "$new" || -z "${_comps[$1]}" ]]; then
+              _comps[$cmd]="$func"
+	      [[ -n "$svc" ]] && _services[$cmd]="${1#*\=}"
+	    fi
+            ;;
+          esac
         fi
+        shift
       done
       ;;
     esac
   else
     # Handle the `-d' option, deleting.
 
-    if [[ $1 = -T ]]; then
-      shift
-      if (( ! $# )); then
-        echo "$0: missing type"
-        return 1
-      fi
-      _comp_assocs=( "$_comp_assocs[@]" "$1" )
-      typeset -gA _$1 _service$1 _pat$1 _postpat$1
-      assoc="$1"
-      shift
-    fi
-
     case "$type" in
     pattern)
-      unset "_pat${assoc}[$^@]"
+      unset "_patcomps[$^@]"
       ;;
     postpattern)
-      unset "_postpat${assoc}[$^@]"
+      unset "_postpatcomps[$^@]"
       ;;
     key)
       # Oops, cannot do that yet.
@@ -462,7 +393,7 @@
       return 1
       ;;
     *)
-      unset "_${assoc}[$^@]"
+      unset "_comps[$^@]"
     esac
   fi
 }
Index: Completion/Base/Completer/_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_complete,v
retrieving revision 1.4
diff -u -r1.4 _complete
--- Completion/Base/Completer/_complete	4 Mar 2002 08:53:42 -0000	1.4
+++ Completion/Base/Completer/_complete	13 Mar 2002 09:20:36 -0000
@@ -95,7 +95,7 @@
 
 comp="$_comps[-first-]"
 if [[ -n "$comp" ]]; then
-  service="${_servicecomps[-first-]:--first-}"
+  service="${_services[-first-]:--first-}"
   ccarray[3]=-first-
   eval "$comp" && ret=0
   if [[ "$_compskip" = all ]]; then
@@ -124,7 +124,7 @@
   ccarray[3]="$cname"
 
   comp="$_comps[$cname]"
-  service="${_servicecomps[$cname]:-$cname}"
+  service="${_services[$cname]:-$cname}"
 
   # If not, we use default completion, if any.
 
@@ -134,7 +134,7 @@
       return 1
     fi
     comp="$_comps[-default-]"
-    service="${_servicecomps[-default-]:--default-}"
+    service="${_services[-default-]:--default-}"
   fi
   [[ -n "$comp" ]] && eval "$comp" && ret=0
 fi
Index: Completion/Base/Core/_dispatch
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_dispatch,v
retrieving revision 1.1
diff -u -r1.1 _dispatch
--- Completion/Base/Core/_dispatch	4 Mar 2002 08:53:43 -0000	1.1
+++ Completion/Base/Core/_dispatch	13 Mar 2002 09:20:36 -0000
@@ -1,31 +1,17 @@
 #autoload
 
 local comp pat val name i ret=1 _compskip="$_compskip"
-local curcontext="$curcontext" service str comptype noskip def
-local __comps __patcomps __postpatcomps __services
+local curcontext="$curcontext" service str noskip
 
 # If we get the option `-s', we don't reset `_compskip'.
 
-while [[ "$1" = -[sd] ]]; do
-  if [[ "$1" = -s ]]; then
-    noskip=yes
-  else
-    def=yes
-  fi
-  shift
-done
+if [[ "$1" = -s ]]; then
+  noskip=yes
+fi
 
 [[ -z "$noskip" ]] && _compskip=
 
-comptype=$1
-
-__comps=_$1
-
-(( ${(P)+__comps} )) || return 1
-
-__patcomps=_pat$1
-__postpatcomps=_postpat$1
-__services=_service$1
+curcontext="${curcontext%:*:*}:${1}:"
 
 shift
 
@@ -35,9 +21,9 @@
 
   for str in "$@"; do
     [[ -n "$str" ]] || continue
-    service="${${(e):-\$${__services}[\$str]}:-$str}"
-    for i in "${(@e):-\$${__patcomps}[(K)\$str]}"; do
-      "$i" && ret=0
+    service="${_services[$str]:-$str}"
+    for i in "${(@)_patcomps[(K)$str]}"; do
+      eval "$i" && ret=0
       if [[ "$_compskip" = *patterns* ]]; then
         break
       elif [[ "$_compskip" = all ]]; then
@@ -54,30 +40,27 @@
 for str in "$@"; do
   [[ -n "$str" ]] || continue
   name="$str"
-  comp="${(e):-\$${__comps}[\$str]}"
-  service="${${(e):-\$${__services}[\$str]}:-$str}"
+  comp="${_comps[$str]}"
+  service="${_services[$str]:-$str}"
 
   [[ -z "$comp" ]] || break
 done
 
 # And generate the matches, probably using default completion.
 
-if [[ -n "$comp" ]]; then
+if [[ -n "$comp" && "$name" != "${argv[-1]}" ]]; then
   _compskip=patterns
   eval "$comp" && ret=0
   [[ "$_compskip" = (all|*patterns*) ]] && return ret
-elif [[ "$_compskip" != *default* ]]; then
-  name=-default-
-  comp="${(e):-\$${__comps}[-default-]}"
 fi
 
 if [[ "$_compskip" != (all|*patterns*) ]]; then
   for str; do
     [[ -n "$str" ]] || continue
-    service="${${(e):-\$${__services}[\$str]}:-$str}"
-    for i in "${(@e):-\$${__postpatcomps}[(K)\$str]}"; do
+    service="${_services[$str]:-$str}"
+    for i in "${(@)_postpatcomps[(K)$str]}"; do
       _compskip=default
-      "$i" && ret=0
+      eval "$i" && ret=0
       if [[ "$_compskip" = *patterns* ]]; then
         break
       elif [[ "$_compskip" = all ]]; then
@@ -88,9 +71,9 @@
   done
 fi
 
-[[ "$name" = -default- && -n "$comp" &&
+[[ "$name" = "${argv[-1]}" && -n "$comp" &&
    "$_compskip" != (all|*default*) ]] &&
-  service="${${(e):-\$${__services}[-default-]}:--default-}" &&
+  service="${_services[$name]:-$name}" &&
    eval "$comp" && ret=0
 
 _compskip=''
Index: Completion/Base/Core/_normal
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_normal,v
retrieving revision 1.3
diff -u -r1.3 _normal
--- Completion/Base/Core/_normal	4 Mar 2002 08:53:43 -0000	1.3
+++ Completion/Base/Core/_normal	13 Mar 2002 09:20:36 -0000
@@ -1,6 +1,6 @@
 #compdef -command-line-
 
-local _comp_command1 _comp_command2 skip
+local _comp_command1 _comp_command2 _comp_command skip
 
 if [[ "$1" = -s ]]; then
   skip=(-s)
@@ -22,4 +22,5 @@
 
 _set_command
 
-_dispatch -d "$skip[@]" comps "$_comp_command1" "$_comp_command2"
+_dispatch "$skip[@]" "$_comp_command" \
+          "$_comp_command1" "$_comp_command2" -default-
Index: Completion/Base/Utility/_set_command
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_set_command,v
retrieving revision 1.1
diff -u -r1.1 _set_command
--- Completion/Base/Utility/_set_command	4 Mar 2002 08:53:43 -0000	1.1
+++ Completion/Base/Utility/_set_command	13 Mar 2002 09:20:36 -0000
@@ -1,7 +1,7 @@
 #autoload
 
-# This sets the parameters _comp_command1 and _comp_command2 in the
-# calling function.
+# This sets the parameters _comp_command1, _comp_command2 and _comp_command
+# in the calling function.
 
 local command
 
@@ -11,21 +11,21 @@
 
 if (( $+builtins[$command] + $+functions[$command] )); then
   _comp_command1="$command"
-  curcontext="${curcontext%:*:*}:${_comp_command1}:"
+  _comp_command="$_comp_command1"
 elif [[ "$command[1]" = '=' ]]; then
   eval _comp_command2\=$command
   _comp_command1="$command[2,-1]"
-  curcontext="${curcontext%:*:*}:${_comp_command2}:"
+  _comp_command="$_comp_command2"
 elif [[ "$command" = ..#/* ]]; then
   _comp_command1="${PWD}/$command"
   _comp_command2="${command:t}"
-  curcontext="${curcontext%:*:*}:${_comp_command2}:"
+  _comp_command="$_comp_command2"
 elif [[ "$command" = */* ]]; then
   _comp_command1="$command"
   _comp_command2="${command:t}"
-  curcontext="${curcontext%:*:*}:${_comp_command2}:"
+  _comp_command="$_comp_command2"
 else
   _comp_command1="$command"
   _comp_command2="$commands[$command]"
-  curcontext="${curcontext%:*:*}:${_comp_command1}:"
+  _comp_command="$_comp_command1"
 fi
Index: Completion/Unix/Command/_gcc
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_gcc,v
retrieving revision 1.4
diff -u -r1.4 _gcc
--- Completion/Unix/Command/_gcc	6 Mar 2002 14:22:41 -0000	1.4
+++ Completion/Unix/Command/_gcc	13 Mar 2002 09:20:37 -0000
@@ -1,13 +1,13 @@
-#compdef gcc g++ -T values LDFLAGS CFLAGS CPPFLAGS
+#compdef gcc g++ -value-,LDFLAGS,-default- -value-,CFLAGS,-default- -value-,CPPFLAGS,-default-
 
 local curcontext="$curcontext" state line ret=1 expl args args2
 typeset -A opt_args
 
-if [[ "$comptype" = values ]]; then
+if [[ "$service" = -value-* ]]; then
   compset -q
   words=( fake "$words[@]" )
   (( CURRENT++ ))
-  if [[ "$service" = LDFLAGS ]]; then
+  if [[ "$service" = *LDFLAGS ]]; then
     args2=( '-R:runtime path:->rundir' )
   else
     args2=()
Index: Completion/Unix/Command/_make
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_make,v
retrieving revision 1.1
diff -u -r1.1 _make
--- Completion/Unix/Command/_make	2 Apr 2001 11:56:47 -0000	1.1
+++ Completion/Unix/Command/_make	13 Mar 2002 09:20:37 -0000
@@ -45,6 +45,7 @@
     fi
     _wanted targets expl 'make target' compadd -a tmp && return 0
   fi
+  compstate[parameter]="${PREFIX%%\=*}"
   compset -P 1 '*='
-  _files
+  _value "$@"
 fi
Index: Completion/Unix/Command/_su
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_su,v
retrieving revision 1.3
diff -u -r1.3 _su
--- Completion/Unix/Command/_su	4 Mar 2002 08:53:43 -0000	1.3
+++ Completion/Unix/Command/_su	13 Mar 2002 09:20:37 -0000
@@ -17,4 +17,4 @@
 shell="${${(M@)${(@f)$(</etc/passwd)}:#$usr*}##*:}"
 compset -n $base
 
-_dispatch comps $shell $shell:t -default-
+_dispatch $shell:t $shell $shell:t -default-
Index: Completion/Unix/Type/_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_files,v
retrieving revision 1.6
diff -u -r1.6 _files
--- Completion/Unix/Type/_files	4 Mar 2002 08:53:43 -0000	1.6
+++ Completion/Unix/Type/_files	13 Mar 2002 09:20:37 -0000
@@ -1,4 +1,4 @@
-#compdef -T redirs -default-
+#compdef -redirect-,-default-,-default-
 
 local opts tmp glob pat pats expl tag i def descr end ign ret=1 match tried
 local type sdef
Index: Completion/Unix/Type/_locales
===================================================================
RCS file: Completion/Unix/Type/_locales
diff -N Completion/Unix/Type/_locales
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ Completion/Unix/Type/_locales	13 Mar 2002 09:20:37 -0000
@@ -0,0 +1,11 @@
+#compdef -value-,LANG,-default- -P -value-,LC_*,-default-
+
+local locales
+
+if (( $+commands[locale] )); then
+  locales=( $(_call_program locales locale -a) )
+else
+  locales=( /usr/lib/locale/*(:t) )
+fi
+
+_wanted locales expl locale compadd "$@" -a locales
Index: Completion/Unix/Type/_printers
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_printers,v
retrieving revision 1.3
diff -u -r1.3 _printers
--- Completion/Unix/Type/_printers	4 Mar 2002 08:53:43 -0000	1.3
+++ Completion/Unix/Type/_printers	13 Mar 2002 09:20:37 -0000
@@ -1,4 +1,4 @@
-#compdef -T values PRINTER LPDEST
+#compdef -value-,PRINTER,-default- -value-,LPDEST,-default-
 
 local expl ret=1 list disp sep
 
Index: Completion/Unix/Type/_terminals
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_terminals,v
retrieving revision 1.2
diff -u -r1.2 _terminals
--- Completion/Unix/Type/_terminals	4 Mar 2002 08:53:43 -0000	1.2
+++ Completion/Unix/Type/_terminals	13 Mar 2002 09:20:37 -0000
@@ -1,4 +1,4 @@
-#compdef infocmp -T values TERM
+#compdef infocmp -value-,TERM,-default-
 
 local desc expl
 
Index: Completion/Unix/Type/_time_zone
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_time_zone,v
retrieving revision 1.4
diff -u -r1.4 _time_zone
--- Completion/Unix/Type/_time_zone	4 Mar 2002 08:53:43 -0000	1.4
+++ Completion/Unix/Type/_time_zone	13 Mar 2002 09:20:37 -0000
@@ -1,4 +1,4 @@
-#compdef -T values TZ
+#compdef -value-,TZ,-default-
 
 local expl
 
Index: Completion/X/Type/_x_display
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Type/_x_display,v
retrieving revision 1.2
diff -u -r1.2 _x_display
--- Completion/X/Type/_x_display	4 Mar 2002 08:53:43 -0000	1.2
+++ Completion/X/Type/_x_display	13 Mar 2002 09:20:37 -0000
@@ -1,3 +1,3 @@
-#compdef -T values DISPLAY
+#compdef -value-,DISPLAY,-default-
 
 _tags displays && _hosts -S ':0 ' -r :
Index: Completion/Zsh/Command/_compdef
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Command/_compdef,v
retrieving revision 1.2
diff -u -r1.2 _compdef
--- Completion/Zsh/Command/_compdef	4 Mar 2002 08:53:43 -0000	1.2
+++ Completion/Zsh/Command/_compdef	13 Mar 2002 09:20:37 -0000
@@ -1,24 +1,37 @@
 #compdef compdef
 
-local state line expl list disp curcontext="$curcontext"
+local state line expl list disp curcontext="$curcontext" pat normal ret=1
+local args1 args2
 typeset -A opt_args
 
-_arguments -C -s -A "-*" -S \
-  '(-d)-a[make function autoloadable]' \
-  '(-d -p -P)-n[leave existing definitions intact]' \
-  "*-T[select type of completion function]:completion function type:($_comp_assocs)" \
+args2=()
+if (( ! ${words[2,-1][(I)[^-]*]} || ${words[(I)-[kK]]} )); then
+  args1=(
+    -A '-*'
+    '(-d)-a[make function autoloadable]'
+    '(-d)-n[leave existing definitions intact]'
+  )
+  args2=(
+     - d
+      '(-a -n)-d[delete]:*:completed command:->ccom'
+     - k
+      '-k[define widget and key binding]:completion function:->cfun:style:->style:*:key'
+     - K
+      '-K[define multiple widgets based on function]:*::: :->multi'
+  )
+else
+  args1=(
+    '-N[completion for named command]'
+  )
+fi
+
+_arguments -C -s -S \
+  "$args1[@]" \
+  '-p[completion for command matching pattern]' \
+  '-P[completion for command matching pattern]' \
   ':completion function:->cfun' \
-  '*:commands: _command_names' \
- - d \
-  '(-a -n)-d[delete]:*:completed command:->ccom' \
- - p \
-  '(-n)-p[completion for command matching pattern]:completion function:->cfun:pattern' \
- - P \
-  '(-n)-P[as -p for commands without own completion]:completion function:->cfun:pattern' \
- - k \
-  '-k[define widget and key binding]:completion function:->cfun:style:->style:*:key' \
- - K \
-  '-K[define multiple widgets based on function]:*::: :->multi' && return 0
+  '*:commands:->com' \
+  "$args2[@]" && return 0
 
 if [[ $state = multi ]]; then
   case $(( CURRENT % 3 )) in
@@ -30,6 +43,15 @@
 fi
 
 case $state in
+  com)
+    pat="${words[(I)-[pP]]}"
+    normal="${words[(I)-N]}"
+    if (( pat && pat > normal )); then
+      _message -e patterns 'pattern'
+    else
+      _command_names
+    fi
+  ;;
   ccom)
     _wanted commands expl 'completed command' compadd -k _comps
   ;;
Index: Completion/Zsh/Context/_in_vared
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Context/_in_vared,v
retrieving revision 1.2
diff -u -r1.2 _in_vared
--- Completion/Zsh/Context/_in_vared	4 Mar 2002 08:53:43 -0000	1.2
+++ Completion/Zsh/Context/_in_vared	13 Mar 2002 09:20:37 -0000
@@ -32,4 +32,4 @@
 
 compstate[insert]="${compstate[insert]//tab /}"
 
-_dispatch comps "$also"
+_dispatch "$also" "$also"
Index: Completion/Zsh/Context/_redirect
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Context/_redirect,v
retrieving revision 1.2
diff -u -r1.2 _redirect
--- Completion/Zsh/Context/_redirect	4 Mar 2002 08:53:43 -0000	1.2
+++ Completion/Zsh/Context/_redirect	13 Mar 2002 09:20:37 -0000
@@ -1,17 +1,16 @@
 #compdef -redirect-
 
-# This searches for `<command-name>:<redir-op>' and `<redir-op>', where
-# `<redir-op>' is something like `<' or `2>'.
-
-local strs _comp_command1 _comp_command2
+local strs _comp_command1 _comp_command2 _comp_command
 
 _set_command
 
-strs=( "$compstate[redirect]" )
+strs=( -default- )
 
 if [[ -n "$_comp_command1" ]]; then
-  strs=( "${_comp_command1}:$strs[-1]" "$strs[@]" )
-  [[ -n "$_comp_command2" ]] && strs=( "${_comp_command2}:$strs[1]" "$strs[@]" )
+  strs=( "${_comp_command1}" "$strs[@]" )
+  [[ -n "$_comp_command2" ]] &&
+      strs=( "${_comp_command2}" "$strs[@]" )
 fi
 
-_dispatch -d redirs "$strs[@]"
+_dispatch -redirect-,${compstate[redirect]},${_comp_command} \
+          -redirect-,{${compstate[redirect]},-default-},${^strs}
Index: Completion/Zsh/Context/_subscript
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Context/_subscript,v
retrieving revision 1.9
diff -u -r1.9 _subscript
--- Completion/Zsh/Context/_subscript	4 Mar 2002 08:53:43 -0000	1.9
+++ Completion/Zsh/Context/_subscript	13 Mar 2002 09:20:37 -0000
@@ -113,5 +113,5 @@
 
   return 1
 else
-  _dispatch comps -math-
+  _dispatch -math- -math-
 fi
Index: Completion/Zsh/Context/_value
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Context/_value,v
retrieving revision 1.5
diff -u -r1.5 _value
--- Completion/Zsh/Context/_value	4 Mar 2002 08:53:43 -0000	1.5
+++ Completion/Zsh/Context/_value	13 Mar 2002 09:20:37 -0000
@@ -1,4 +1,4 @@
-#compdef -value- -array-value- -T values -default-
+#compdef -value- -array-value- -value-,-default-,-default-
 
 # You can customize completion for different parameters by writing
 # functions with the tag-line `#compdef -T value <name>'.
@@ -6,30 +6,20 @@
 # and `<param-name>'. If the line contains a command (as in `make foo=<TAB>')
 # the string `<command>:<param-name>:<param-type>' is also searched for.
 
-if [[ "$service" != -default- ]]; then
-  local strs type
+if [[ "$service" != -value-,* ]]; then
+  local strs ctx=
 
-  type="${(Pt)compstate[parameter]}"
-
-  if [[ -z "$type" ]]; then
-    if [[ "$compstate[parameter]" = *-* ]]; then
-      type=association-value
-    elif [[ "$compstate[context]" = value ]]; then
-      type=scalar
-    else
-      type=array
-    fi
-  fi
-
-  strs=( "${compstate[parameter]}:$type" "$compstate[parameter]" )
+  strs=( -default- )
 
   if [[ "$compstate[context]" != *value && -n "$_comp_command1" ]]; then
-    strs=( "${_comp_command1}:$^strs[@]" "$strs[@]" )
+    ctx="${_comp_command}"
+    strs=( "${_comp_command1}" "$strs[@]" )
     [[ -n "$_comp_command2" ]] &&
-        strs=( "${_comp_command2}:${(@)^strs[-2,-1]}" "$strs[@]" )
+        strs=( "${_comp_command2}" "$strs[@]" )
   fi
 
-  _dispatch -d values "$strs[@]"
+  _dispatch -value-,${compstate[parameter]},$ctx \
+            -value-,{${compstate[parameter]},-default-},${^strs}
 else
   if [[ "$compstate[parameter]" != *-* &&
         "$compstate[context]" = *value &&
@@ -39,7 +29,9 @@
           compadd -k "$compstate[parameter]"
     else
       compstate[parameter]="${compstate[parameter]}-${words[CURRENT-1]}"
-      _value "$@"
+
+      _dispatch -value-,${compstate[parameter]}, \
+                -value-,{${compstate[parameter]},-default-},-default-
     fi
   else
     local pats
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.147
diff -u -r1.147 compsys.yo
--- Doc/Zsh/compsys.yo	4 Mar 2002 08:53:43 -0000	1.147
+++ Doc/Zsh/compsys.yo	13 Mar 2002 09:20:37 -0000
@@ -159,7 +159,8 @@
 The tags are:
 
 startitem()
-item(tt(#compdef) var(names...))(
+item(tt(#compdef) var(names...) [ tt(-[pP]) var(patterns...) [ tt(-N)
+var(names...) ] ])(
 The file will be made autoloadable and the function defined 
 in it will be called when completing var(names), each of which is
 either the name of a command whose arguments are to be completed or one of
@@ -174,33 +175,18 @@
 to the string `tt(service)'.  The function can then use that parameter 
 to decide what to complete.
 
-Finally, the list of var(names) may contain tt(-T) options, each
-followed by a type name.  These type names describe in which set of
-completion function definitions the function is to be stored.  The
-default without a tt(-T) option is `tt(comps)', saying that the
-function is a normal completion function.  Other type names currently
-understood by the completion system are tt(redirs) and tt(values).
-The first is used to define specialised completion functions for
-use after redirection operators for certain commands and the latter is
-used to define functions used when completing values of parameters.
-For example, to define the function that should be used when
-completing after `tt(foo=<TAB>)' one would use the tag line:
-
-example(#compdef -T values foo)
-
-When the function is called, the parameter tt($comptype) will be set
-to the type name, making it easy to distinguish what should be
-completed.
-)
-item(tt(#compdef -p) var(patterns...))(
-The file will be made autoloadable and the function defined in it will be
-called when completing for a command whose name matches the given
-var(pattern) (a standard globbing pattern).  As in the first case, the
-list of var(patterns) may contain tt(-T) options.
-)
-item(tt(#compdef -P) var(patterns...))(
-Like the previous one, but the function will be called only if no
-completion function for the command on the line could be found.
+If the list of var(names) contains a tt(-p) or tt(-P) option, the
+following words are taken to be patterns.  When completing for a
+command or context whose name matches one of the patterns, the
+function will be called.  In the case of tt(-P), this will only be
+done if no other completion function for the command or context could
+be found (i.e. this can be used to define default completion for
+commands or contexts matching one of the patterns which don't have a
+completion function specifically defined for them).
+
+If the list contains the tt(-N) option, the following words are used
+as in the normal case again.  Another tt(-p) or tt(-P) option can be
+usedto toggle back to defining patterns again. 
 )
 item(tt(#compdef -k) var(style key-sequences...))(
 This can be used to bind special completion functions to the
@@ -272,10 +258,8 @@
 findex(compdef)
 cindex(completion system, adding definitions)
 startitem()
-xitem(tt(compdef) [ tt(-an) ] var(function names) [ tt(-T) var(type) ] ...))
-xitem(tt(compdef -d) [ tt(-T) var(type) ] var(names...))
-xitem(tt(compdef -p) [ tt(-a) ] var(function patterns) [ tt(-T) var(type) ] ...)
-xitem(tt(compdef -P) [ tt(-a) ] var(function patterns) [ tt(-T) var(type) ] ...)
+xitem(tt(compdef) [ tt(-an) ] var(function names...) [ tt(-[pP]) var(patterns...) ])
+xitem(tt(compdef -d) var(names...))
 xitem(tt(compdef -k) [ tt(-an) ] var(function style key-sequences...))
 item(tt(compdef -K) [ tt(-an) ] var(function name style key-sequences ...))(
 The first form tells the completion system to call the given
@@ -297,27 +281,25 @@
 
 example(compdef '_files -g "*.h"' foo)
 
-The tt(-T) options in the list of var(names) define for which type of
-completions the function is to be used, i.e. in which set of
-completion functions definitions it should be added.  Currently used
-tt(type)s are tt(comps) (the default, for normal completion functions
-for command completion), tt(values) for completion of parameter values
-in assignments and tt(redirs) for completion after redirection
-operators.
-
 If the
 tt(-n) option is given, any existing completion behaviour for particular
 contexts or commands will not be altered.  These definitions can be deleted
 by giving the tt(-d) option as in the second form.
 
-The form with tt(-p) is similar to the first, but var(function) will be
-called for all commands whose name matches the var(pattern); this is like
-the tt(#compdef -p) function tag.
-
-The form with tt(-P) is like the third, but the var(function) will be
-called only if no function for the command itself was found or if one
-was found and it set the tt(_compskip) parameter to a value em(not)
-containing the substring tt(patterns).
+In both of the first two cases forms and as for the tt(#compdef) tag
+described above, the var(names) may also contain tt(-p), tt(-P) and
+tt(-N) options.  The first two make the following arguments be used as
+patterns and the var(function) will be called for all commands and
+contexts matching one of the patterns.  Wtih tt(-P) this will only
+happen if no specific function is defined for the command or context.
+The tt(-N) option toggles back to using the var(names) as described
+above.
+
+Inside functions defined for patterns, the parameter tt($_compskip)
+may be used.  If it is set to a value containing the substring
+`tt(patterns)' none of the pattern-functions will be called.  If it is
+set to a value containing the substring `tt(all)', no other function
+will be called.
 
 The form with tt(-k) defines a widget with the same name as the var(function)
 which will be called for each of the var(key-sequences); this is like the
@@ -2566,6 +2548,56 @@
 (e.g. completion for the `tt(-tilde-)' context is done by the function 
 named `tt(_tilde)').
 
+The functions for some contexts re-dispatch by calling the function
+tt(_dispatch) to offer more specific context information.  This is
+done by appending the parts of extra information to the name of the
+context, separated by commas.  Currently, only the function
+completing redirection arguments (tt(_redirect)) and the function
+completing values in parameter assignments (tt(_value)) use this
+feature.  The former uses contexts of the form
+`tt(-redirect-,)var(op)tt(,)var(command)', where var(op) is the
+redirection operator and var(command) is the name of the command on
+the line.  If there isn't a command yet, the var(command) field will
+be empty.  The function completing values uses contexts of the form
+`tt(-value-,)var(name)tt(,)var(command)', where var(name) is the name
+of the parameter (or `var(name)tt(-)var(key)' when completing a
+value of an associative array in an assignment like
+`tt(assoc=LPAR()key <TAB>)').  The var(command) part is the name of
+the command from the line again in completions like `tt(make
+CFLAGS=<TAB>)' and is empty for normal assignments.
+
+To simplify defining functions for multiple cases, the functions
+tt(_redirect) and tt(_value) will make tt(_dispatch) try these context
+names more than once with each of the parts once set to the string
+tt(-default-).  For example, when completing after `tt(foo=<TAB>)',
+tt(_value) will try the names `tt(-value-,foo,)' (note the empty
+var(command) part), `tt(-value-,foo,-default-)' and
+`tt(-value-,-default-,-default-)'.  Also note the order in which the
+contexts are tried.
+
+As an example:
+
+example(compdef '_files -g "*.log"' '-redirect-,2>,-default-')
+
+could be used to complete files matching `tt(*.log)' when completing
+after `tt(2> <TAB>)'.
+
+And:
+
+example(compdef _foo -value-,-default-,-default-)
+
+says that the function tt(_foo) is to be called to provide completion
+for the values of parameters for which no special function has been
+defined.
+
+In any case the most specific context name will be used inside the
+context string used for looking up styles.  For example:
+
+example(zstyle ':completion:*:*:-redirect-,2>,*:*' file-patterns '*.log')
+
+is another way to make completion after `tt(2> <TAB>)' complete files
+matching `tt(*.log)'.
+
 Before trying to find a function for a specific context, tt(_complete) 
 checks if the parameter `tt(compcontext)' is set.  If it is set to an
 array, the elements are taken to be the possible matches which will be
@@ -3657,17 +3689,16 @@
 passed down to the builtins which implement the internals of completion.
 )
 findex(_dispatch)
-item(tt(_dispatch) [ tt(-d) ] var(type strings ...))(
-This function looks up the function defined for the first var(string)
-in the set of definitions named var(type) (these are those definitions
-defined with `tt(-T )var(type)').  If one is found, it is called to
-generate completions.  Otherwise the definition for the second
-var(string) is looked up and so on.  If none is found and the tt(-d)
-option is given, the definition for the special name tt(-default-) is
-used.
-
-This function is the one responsible for setting the parameters
-tt($service) and tt($comptype).
+item(tt(_dispatch) var(context strings ...))(
+This looks up the functions defined for the var(strings) one after
+another until it finds one that is defined. That function is then
+called to generate the matches.  Normally, the last var(string) is the
+one used to look up the default completion.
+
+This function is the one responsible for setting the parameter
+tt($service) (to the var(strings) as they are tried) and for setting
+the var(context/command) field of the tt($curcontext) parameter (to
+the var(context) given as the first argument).
 )
 findex(_files)
 item(tt(_files))(
Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_tricky.c,v
retrieving revision 1.34
diff -u -r1.34 zle_tricky.c
--- Src/Zle/zle_tricky.c	7 Mar 2002 08:38:44 -0000	1.34
+++ Src/Zle/zle_tricky.c	13 Mar 2002 09:20:37 -0000
@@ -856,6 +856,7 @@
 	(iblank(line[cs]) && (!cs || line[cs-1] != '\\')) ||
 	line[cs] == ')' || line[cs] == '`' || line[cs] == '}' ||
 	line[cs] == ';' || line[cs] == '|' || line[cs] == '&' ||
+	line[cs] == '>' || line[cs] == '<' ||
 	(instring && (line[cs] == '"' || line[cs] == '\'')) ||
 	(addspace = (comppref && !iblank(line[cs])))) {
 	*ptmp = (char *)line;

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Peter Stephenson]

Sven Wischnowsky wrote:
> It uses the comma-separated sub-contexts discussed. For values it is
> `-value-,<name>,<cmd>', so I've not put the parameter type in it, as
> suggested by Oliver. For redirection it is `-redirect-,<op>,<cmd>'.

The following redirections for compressed files seem to work quite
nicely --- uncompress input from the appropriate compressed file type, and
compress output into it.  Was anyone planning anything more sophisticated?

> For example, completion after `foo=<TAB>' makes _value try:
> 
>   1) -value-,foo,
>   2) -value-,foo,-default-
>   3) -value-,-default-,-default-
> 
> in this order.

It seems vaguely preferable to allow the user to omit trailing
`,-default-' bits when defining commands (it's not important in style
contexts since you would usually use a wildcard anyway), but it doesn't
actually gain you anything apart from laxity.

> I.e.:
> should `-redirect-,-default-,echo' or `-redirect-,>,-default-' take
> precedence?

It seems more logical that the command variant should take precedence,
although the order of the parts would imply otherwise.

> And another question where the default-handling is important is: when
> should post-patterns (-P) be tried? Currently this is done only if we
> would otherwise use the function defined for the least specific
> context (the one with all parts being `-default-').

This seems OK unless we do something more complicated with pattern
handling, e.g. some way of matching the point at which you want the
pattern tried.  But I don't see any great call for that at the moment.

Index: Completion/Unix/Command/_bzip2
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_bzip2,v
retrieving revision 1.1
diff -u -r1.1 _bzip2
--- Completion/Unix/Command/_bzip2	2 Apr 2001 11:46:03 -0000	1.1
+++ Completion/Unix/Command/_bzip2	13 Mar 2002 16:34:23 -0000
@@ -1,4 +1,4 @@
-#compdef bzip2 bunzip2 bzcat=bunzip2 bzip2recover
+#compdef bzip2 bunzip2 bzcat=bunzip2 bzip2recover -redirect-,<,bunzip2=bunzip2 -redirect-,>,bzip2=bunzip2
 
 local decompress expl state line curcontext="$curcontext"
 typeset -A opt_args
Index: Completion/Unix/Command/_compress
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_compress,v
retrieving revision 1.1
diff -u -r1.1 _compress
--- Completion/Unix/Command/_compress	2 Apr 2001 11:46:37 -0000	1.1
+++ Completion/Unix/Command/_compress	13 Mar 2002 16:34:23 -0000
@@ -1,4 +1,4 @@
-#compdef compress uncompress
+#compdef compress uncompress -redirect-,<,uncompress=uncompress -redirect-,>,compress=uncompress
 
 local expl state line bits common_args1 common_args2 decompress
 local curcontext="$curcontext"
Index: Completion/Unix/Command/_gzip
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_gzip,v
retrieving revision 1.2
diff -u -r1.2 _gzip
--- Completion/Unix/Command/_gzip	31 Jul 2001 13:54:04 -0000	1.2
+++ Completion/Unix/Command/_gzip	13 Mar 2002 16:34:23 -0000
@@ -1,4 +1,4 @@
-#compdef gzip gunzip gzcat=gunzip
+#compdef gzip gunzip gzcat=gunzip -redirect-,<,gunzip=gunzip -redirect-,>,gzip=gunzip
 
 local decompress expl curcontext="$curcontext" state line
 typeset -A opt_args

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Redirection completion

[Oliver Kiddle]

Sven wrote:

> And another question where the default-handling is important is: when
> should post-patterns (-P) be tried? Currently this is done only if we
> would otherwise use the function defined for the least specific
> context (the one with all parts being `-default-').

Hmm, we might want to define -redirect-,<,-default- and would want
patterns tried before that. I think the post-patterns should perhaps be
tried just before -default- is first tried in the command position for
redirection and in the parameter name position for values. Or perhaps,
we need to look to see where each post-pattern uses -default-. If it
uses a pattern for one part then we should use it before trying
-default- for that part. We might need to require patterns to all be
of the form -whatever-,pattern,pattern.

> Can't say anything about this without more information. Have you
> remembered to remove the dump-file?

I had. I'm not sure what was wrong but it all works now with the latest
patch. I may have had an old version of a function in my ~/.zfunc.

> Aha. Ugh. No. See above, `-redirect-,-default-,gzip' etc. are enough.
> Not that short either, I admit, but allowing braces there isn't *that*
> simple (well, it isn't that hard either, a bit of `eval' with an array
> and some quoting magic, but...).

Ah, that is better, and neater than braces. I hadn't picked up on that
part of the idea. Very neat.

The patch below does the GZIP thing I mentioned. I've also added
pattern completions for *PATH and *path parameters using _dir_list and
_directories respectively. I've not thought of any exceptions where
this isn't appropriate but I'll leave sufficient time for objections
before committing.

Oliver

Index: Completion/Unix/Command/_gzip
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_gzip,v
retrieving revision 1.2
diff -u -r1.2 _gzip
--- Completion/Unix/Command/_gzip	31 Jul 2001 13:54:04 -0000	1.2
+++ Completion/Unix/Command/_gzip	13 Mar 2002 17:17:05 -0000
@@ -1,9 +1,16 @@
-#compdef gzip gunzip gzcat=gunzip
+#compdef gzip gunzip gzcat=gunzip -value-,GZIP,-default-
 
-local decompress expl curcontext="$curcontext" state line
+local decompress files expl curcontext="$curcontext" state line
 typeset -A opt_args
 
+files=( '*:files:->files' )
 case "$service" in
+*GZIP*)
+  compset -q
+  words=( fake "$words[@]" )
+  (( CURRENT++ ))
+  files=()
+  ;&
 gunzip|zcat)
   decompress=yes
   ;&
@@ -51,7 +58,7 @@
     '(--fast -1 -2 -3 -4 -5 -6 -7    -9 --best)-8' \
     '(--fast -1 -2 -3 -4 -5 -6 -7 -8    --best)-9' \
     '(--fast -1 -2 -3 -4 -5 -6 -7 -8 -9       )--best' \
-    '*:files:->files' && return 0
+    "$files[@]" && return 0
   ;;
 esac
 
Index: Completion/Unix/Type/_dir_list
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_dir_list,v
retrieving revision 1.2
diff -u -r1.2 _dir_list
--- Completion/Unix/Type/_dir_list	13 Jun 2001 11:05:51 -0000	1.2
+++ Completion/Unix/Type/_dir_list	13 Mar 2002 17:17:05 -0000
@@ -1,4 +1,4 @@
-#autoload
+#compdef -value-,TERMINFO_DIRS,-default- -P -value-,*PATH,-default-
 
 # options:
 #  -s <sep> to specify the separator (default is a colon)
Index: Completion/Unix/Type/_directories
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_directories,v
retrieving revision 1.4
diff -u -r1.4 _directories
--- Completion/Unix/Type/_directories	20 Feb 2002 12:51:53 -0000	1.4
+++ Completion/Unix/Type/_directories	13 Mar 2002 17:17:05 -0000
@@ -1,4 +1,4 @@
-#compdef rmdir df du dircmp
+#compdef rmdir df du dircmp -P -value-,*path,-default-
 
 local expl
 

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: Redirection completion

[Bart Schaefer]

On Mar 13,  5:58pm, Oliver Kiddle wrote:
}
} The patch below does the GZIP thing I mentioned.

So now you and Peter have submitted conflicting _gzip patches, one using
-redirect- and one using -value-.  Looks to me as if they're both useful,
and should be merged?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Redirection completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> It seems vaguely preferable to allow the user to omit trailing
> `,-default-' bits when defining commands (it's not important in style
> contexts since you would usually use a wildcard anyway), but it doesn't
> actually gain you anything apart from laxity.

That would only work if that would mean to omit the commas, too,
because I think the distinction between an empty field (no command on
the line) and -default- may sometime be good to have. I may be wrong,
of course.

> > I.e.:
> > should `-redirect-,-default-,echo' or `-redirect-,>,-default-' take
> > precedence?
> 
> It seems more logical that the command variant should take precedence,
> although the order of the parts would imply otherwise.

Yes, that's the kind of philosophical question I was thinking about.
The whole style-context name is sorted least-to-most-specific.

Other comments?

> ...
> 
> This seems OK unless we do something more complicated with pattern
> handling, e.g. some way of matching the point at which you want the
> pattern tried.  But I don't see any great call for that at the moment.

Nor do I, really...


Oliver on the same topic:

> Hmm, we might want to define -redirect-,<,-default- and would want
> patterns tried before that. I think the post-patterns should perhaps be
> tried just before -default- is first tried in the command position for
> redirection and in the parameter name position for values. Or perhaps,
> we need to look to see where each post-pattern uses -default-. If it
> uses a pattern for one part then we should use it before trying
> -default- for that part. We might need to require patterns to all be
> of the form -whatever-,pattern,pattern.

I think we should wait until we find something where we need a
different behaviour and then implement that (or the thing that solves
the problem behind the problem). We can add possibilities quite easily
because we already use the $_compskip parameter there (implementation
could be somewhat more complicated, depending on what we want).


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Redirection completion

[Oliver Kiddle]

On Wed, Mar 13, 2002 at 06:19:00PM +0000, Bart Schaefer wrote:
> 
> So now you and Peter have submitted conflicting _gzip patches, one using
> -redirect- and one using -value-.  Looks to me as if they're both useful,
> and should be merged?

If Peter wants to commit his change first, I'll do the merge and
commit my change later. It is only the first line that needs any
merging anyway.

I'd be tempted to add -redirect-,<,bzip2=bzip2 too so that completion
after bzip2 -c < and bzip2 -cd < also work. Ideally, we should stop it
from completing options but it would still need _arguments with ! specs
if the checks for -d and -z options are still to work.

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: Redirection completion

[Peter Stephenson]

Oliver Kiddle wrote:
> If Peter wants to commit his change first, I'll do the merge and
> commit my change later. It is only the first line that needs any
> merging anyway.
> 
> I'd be tempted to add -redirect-,<,bzip2=bzip2 too so that completion
> after bzip2 -c < and bzip2 -cd < also work. Ideally, we should stop it
> from completing options but it would still need _arguments with ! specs
> if the checks for -d and -z options are still to work.

OK, I've done that, except I haven't done anything about option
handling.  It would be better to have special services for the
redirections.  I haven't worked out either whether _arguments is aware
of the options when it's completing redirections.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Redirection completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> Oliver Kiddle wrote:
> > If Peter wants to commit his change first, I'll do the merge and
> > commit my change later. It is only the first line that needs any
> > merging anyway.
> > 
> > I'd be tempted to add -redirect-,<,bzip2=bzip2 too so that completion
> > after bzip2 -c < and bzip2 -cd < also work. Ideally, we should stop it
> > from completing options but it would still need _arguments with ! specs
> > if the checks for -d and -z options are still to work.
> 
> OK, I've done that, except I haven't done anything about option
> handling.  It would be better to have special services for the
> redirections.  I haven't worked out either whether _arguments is aware
> of the options when it's completing redirections.

Err... just to make sure: everyone's aware that $service is set, yes?
I've put an example in _gcc.

Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de