* Redirection completion
@ 2002-03-08 12:33 Peter Stephenson
2002-03-08 12:54 ` Sven Wischnowsky
2002-03-08 13:20 ` Oliver Kiddle
0 siblings, 2 replies; 23+ messages in thread
From: Peter Stephenson @ 2002-03-08 12:33 UTC (permalink / raw)
To: Zsh hackers list
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.
**********************************************************************
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: Redirection completion 2002-03-08 12:33 Redirection completion Peter Stephenson @ 2002-03-08 12:54 ` Sven Wischnowsky 2002-03-08 14:06 ` Peter Stephenson 2002-03-08 13:20 ` Oliver Kiddle 1 sibling, 1 reply; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-08 12:54 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-08 12:54 ` Sven Wischnowsky @ 2002-03-08 14:06 ` Peter Stephenson 2002-03-08 14:10 ` Sven Wischnowsky 0 siblings, 1 reply; 23+ messages in thread From: Peter Stephenson @ 2002-03-08 14:06 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-08 14:06 ` Peter Stephenson @ 2002-03-08 14:10 ` Sven Wischnowsky 2002-03-11 8:42 ` Sven Wischnowsky 0 siblings, 1 reply; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-08 14:10 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-08 14:10 ` Sven Wischnowsky @ 2002-03-11 8:42 ` Sven Wischnowsky 2002-03-11 9:58 ` Sven Wischnowsky ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-11 8:42 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 8:42 ` Sven Wischnowsky @ 2002-03-11 9:58 ` Sven Wischnowsky 2002-03-11 10:54 ` Peter Stephenson 2002-03-12 13:16 ` Oliver Kiddle 2 siblings, 0 replies; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-11 9:58 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 8:42 ` Sven Wischnowsky 2002-03-11 9:58 ` Sven Wischnowsky @ 2002-03-11 10:54 ` Peter Stephenson 2002-03-11 11:16 ` Sven Wischnowsky 2002-03-12 13:16 ` Oliver Kiddle 2 siblings, 1 reply; 23+ messages in thread From: Peter Stephenson @ 2002-03-11 10:54 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 10:54 ` Peter Stephenson @ 2002-03-11 11:16 ` Sven Wischnowsky 2002-03-11 11:29 ` Peter Stephenson 0 siblings, 1 reply; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-11 11:16 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 11:16 ` Sven Wischnowsky @ 2002-03-11 11:29 ` Peter Stephenson 2002-03-11 12:08 ` Sven Wischnowsky 0 siblings, 1 reply; 23+ messages in thread From: Peter Stephenson @ 2002-03-11 11:29 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 11:29 ` Peter Stephenson @ 2002-03-11 12:08 ` Sven Wischnowsky 2002-03-11 14:01 ` Peter Stephenson 2002-03-11 16:56 ` Bart Schaefer 0 siblings, 2 replies; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-11 12:08 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 12:08 ` Sven Wischnowsky @ 2002-03-11 14:01 ` Peter Stephenson 2002-03-11 16:56 ` Bart Schaefer 1 sibling, 0 replies; 23+ messages in thread From: Peter Stephenson @ 2002-03-11 14:01 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 12:08 ` Sven Wischnowsky 2002-03-11 14:01 ` Peter Stephenson @ 2002-03-11 16:56 ` Bart Schaefer 2002-03-12 9:03 ` Sven Wischnowsky 1 sibling, 1 reply; 23+ messages in thread From: Bart Schaefer @ 2002-03-11 16:56 UTC (permalink / raw) To: Sven Wischnowsky, zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 16:56 ` Bart Schaefer @ 2002-03-12 9:03 ` Sven Wischnowsky 0 siblings, 0 replies; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-12 9:03 UTC (permalink / raw) To: zsh-workers [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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-11 8:42 ` Sven Wischnowsky 2002-03-11 9:58 ` Sven Wischnowsky 2002-03-11 10:54 ` Peter Stephenson @ 2002-03-12 13:16 ` Oliver Kiddle 2002-03-13 9:25 ` Sven Wischnowsky 2 siblings, 1 reply; 23+ messages in thread From: Oliver Kiddle @ 2002-03-12 13:16 UTC (permalink / raw) To: Sven Wischnowsky; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-12 13:16 ` Oliver Kiddle @ 2002-03-13 9:25 ` Sven Wischnowsky 2002-03-13 16:55 ` Peter Stephenson 2002-03-13 17:58 ` Oliver Kiddle 0 siblings, 2 replies; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-13 9:25 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-13 9:25 ` Sven Wischnowsky @ 2002-03-13 16:55 ` Peter Stephenson 2002-03-14 12:03 ` Sven Wischnowsky 2002-03-13 17:58 ` Oliver Kiddle 1 sibling, 1 reply; 23+ messages in thread From: Peter Stephenson @ 2002-03-13 16:55 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-13 16:55 ` Peter Stephenson @ 2002-03-14 12:03 ` Sven Wischnowsky 0 siblings, 0 replies; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-14 12:03 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-13 9:25 ` Sven Wischnowsky 2002-03-13 16:55 ` Peter Stephenson @ 2002-03-13 17:58 ` Oliver Kiddle 2002-03-13 18:19 ` Bart Schaefer 1 sibling, 1 reply; 23+ messages in thread From: Oliver Kiddle @ 2002-03-13 17:58 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-13 17:58 ` Oliver Kiddle @ 2002-03-13 18:19 ` Bart Schaefer 2002-03-14 13:51 ` Oliver Kiddle 0 siblings, 1 reply; 23+ messages in thread From: Bart Schaefer @ 2002-03-13 18:19 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-13 18:19 ` Bart Schaefer @ 2002-03-14 13:51 ` Oliver Kiddle 2002-03-14 14:41 ` Peter Stephenson 0 siblings, 1 reply; 23+ messages in thread From: Oliver Kiddle @ 2002-03-14 13:51 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-14 13:51 ` Oliver Kiddle @ 2002-03-14 14:41 ` Peter Stephenson 2002-03-14 14:43 ` Sven Wischnowsky 0 siblings, 1 reply; 23+ messages in thread From: Peter Stephenson @ 2002-03-14 14:41 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-14 14:41 ` Peter Stephenson @ 2002-03-14 14:43 ` Sven Wischnowsky 0 siblings, 0 replies; 23+ messages in thread From: Sven Wischnowsky @ 2002-03-14 14:43 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Redirection completion 2002-03-08 12:33 Redirection completion Peter Stephenson 2002-03-08 12:54 ` Sven Wischnowsky @ 2002-03-08 13:20 ` Oliver Kiddle 1 sibling, 0 replies; 23+ messages in thread From: Oliver Kiddle @ 2002-03-08 13:20 UTC (permalink / raw) To: Zsh hackers list --- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2002-03-14 14:44 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-03-08 12:33 Redirection completion Peter Stephenson 2002-03-08 12:54 ` Sven Wischnowsky 2002-03-08 14:06 ` Peter Stephenson 2002-03-08 14:10 ` Sven Wischnowsky 2002-03-11 8:42 ` Sven Wischnowsky 2002-03-11 9:58 ` Sven Wischnowsky 2002-03-11 10:54 ` Peter Stephenson 2002-03-11 11:16 ` Sven Wischnowsky 2002-03-11 11:29 ` Peter Stephenson 2002-03-11 12:08 ` Sven Wischnowsky 2002-03-11 14:01 ` Peter Stephenson 2002-03-11 16:56 ` Bart Schaefer 2002-03-12 9:03 ` Sven Wischnowsky 2002-03-12 13:16 ` Oliver Kiddle 2002-03-13 9:25 ` Sven Wischnowsky 2002-03-13 16:55 ` Peter Stephenson 2002-03-14 12:03 ` Sven Wischnowsky 2002-03-13 17:58 ` Oliver Kiddle 2002-03-13 18:19 ` Bart Schaefer 2002-03-14 13:51 ` Oliver Kiddle 2002-03-14 14:41 ` Peter Stephenson 2002-03-14 14:43 ` Sven Wischnowsky 2002-03-08 13:20 ` Oliver Kiddle
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).