zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: cleanup
@ 1999-11-18 10:02 Sven Wischnowsky
  0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 1999-11-18 10:02 UTC (permalink / raw)
  To: zsh-workers


I wrote:

> This contains mostly cleanups for the manual stuff.

Damn. Obviously, TABs aren't considered to be eight spaces wide.

Bye
 Sven

diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- olddoc/Zsh/compsys.yo	Thu Nov 18 10:52:23 1999
+++ Doc/Zsh/compsys.yo	Thu Nov 18 11:00:58 1999
@@ -2101,9 +2101,9 @@
 
 example(_arguments '-l+:left border:' \ 
            '-format:paper size:(letter A4)' \ 
-	   '*-copy:output file:_files::resolution:(300 600)' \ 
-	   ':postscript file:_files -g *.(ps|eps)' \ 
-	   '*:page number:')
+           '*-copy:output file:_files::resolution:(300 600)' \ 
+           ':postscript file:_files -g *.(ps|eps)' \ 
+           '*:page number:')
 
 This describes three options: `tt(-l)', `tt(-format)', and
 `tt(-copy)'. The first one gets one argument described as `var(left

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


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

* Re: PATCH: cleanup
  1999-12-15 15:26 Sven Wischnowsky
@ 1999-12-15 20:31 ` Peter Stephenson
  0 siblings, 0 replies; 8+ messages in thread
From: Peter Stephenson @ 1999-12-15 20:31 UTC (permalink / raw)
  To: zsh-workers

Sven Wischnowsky wrote:
> - The tag stuff. First of all, I changed the name of the style to
>   `tag-order' to make it more consistent with `group-order'. I hope
>   this is ok, or should we rename both to `sort-{groups,tags}'?

No, that's fine, I just didn't look round for comparable names.

>   Then I change the interpretion of the value of the style a bit. For
>   one, the code will normally add all offered tags as a default. But
>   you can turn that off by explicitly adding a string consisting of
>   only a minus sign to the value. This is important, I think, because
>   it can be quite tedious to always have to list all tags that are
>   used in particular contexts.

Yes, I realised that problem.  My first vague ides was to do it the other
way around:  have a '*' special value which means try any tags supplied at
that point.  But I think your way is going to be better for most people.

>   Ok, this should give us maximum flexibility. One of the many
>   questions is: is `foo()' a nice syntax or are there better ones?

It seems quite mnicely mnemonic.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>


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

* PATCH: cleanup
@ 1999-12-15 15:26 Sven Wischnowsky
  1999-12-15 20:31 ` Peter Stephenson
  0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 1999-12-15 15:26 UTC (permalink / raw)
  To: zsh-workers


This is mainly a reply to Peter's...

The less interesting things first:

- Fix for the docs: the `complete' style is really named `completions' 
  (as noted by Peter).
- A small fix for the comment in _combination ($opt_args instead of
  $options).
- A fix for _cd: if $cdpath contained `.', the directories in the cwd
  were listed twice.
- (It gets more interesting now...) The prefix-needed style is ignored 
  now when it seems sensible, i.e. it inhibits generation of the
  matches with the prefix only if there are no other matches
  generated. For _jobs this meant to make it be always tried last (and 
  to give it a new option `-t' that says if the test is to be
  performed at all).
  I haven't changed _apt and _socket yet. The former because I don't
  know enough about it to be sure that a simple test of the form
  [[ nm -eq compstate[nmatches] ]] is enough to be sure that there are 
  other matches, etc. In _socket there is another problem, because a
  additional option is generated explicitly. But that isn't that
  dramatic given the fact that this option is `-version'. Maybe we
  should just change the argument-list for _arguments under the
  condition which now triggers adding the `-version'.
- I replaced the `strings' style with `numbers'. As a reminder: this
  says if jobs are to be completed as %1 or %foo. This also means that 
  the default is now to complete them as %foo. To get numbers, one can 
  set the style to true.
  But there is some more trickery: if the value of the style is a
  number, %foo is only used if the longest string needed for any job
  contains at most N words. E.g. if the style is set to `1' you get
  %foo only if all jobs differ in the first word of their command
  lines.
  I hope this makes everybody happy.
- The tag stuff. First of all, I changed the name of the style to
  `tag-order' to make it more consistent with `group-order'. I hope
  this is ok, or should we rename both to `sort-{groups,tags}'?
  Then I moved the test for the style to _tags. This makes things
  faster, of course, and I don't see any reason to call an extra
  function if that is intended to onlytest one style (and Peter's
  changes to the docs suggested to use the style instead).
  Then I change the interpretion of the value of the style a bit. For
  one, the code will normally add all offered tags as a default. But
  you can turn that off by explicitly adding a string consisting of
  only a minus sign to the value. This is important, I think, because
  it can be quite tedious to always have to list all tags that are
  used in particular contexts.
  And then there is another special value-string format: a string of
  the form `foo()' says that the function `foo' should be called,
  which can then use comptry. I also removed the normal call to
  _sort_tags, so that serves only as an example of how such functions
  can be written.
  Ok, this should give us maximum flexibility. One of the many
  questions is: is `foo()' a nice syntax or are there better ones?


Bye
 Sven

diff -ru ../z.old/Completion/Base/_arguments Completion/Base/_arguments
--- ../z.old/Completion/Base/_arguments	Wed Dec 15 09:58:09 1999
+++ Completion/Base/_arguments	Wed Dec 15 10:31:53 1999
@@ -259,7 +259,8 @@
 
       if [[ -z "$matched" ]] && _requested options &&
           { ! zstyle -t ":completion${curcontext}:options" prefix-needed ||
-            [[ "$origpre" = [-+]* ]] } ; then
+            [[ "$origpre" = [-+]* ||
+               ( -z "$aret$mesg" && nm -eq compstate[nmatches] ) ]] } ; then
 	local prevpre="$PREFIX" previpre="$IPREFIX"
 
 	PREFIX="$origpre"
diff -ru ../z.old/Completion/Base/_combination Completion/Base/_combination
--- ../z.old/Completion/Base/_combination	Wed Dec 15 09:58:09 1999
+++ Completion/Base/_combination	Wed Dec 15 10:25:56 1999
@@ -21,7 +21,7 @@
 #  `_telnet' completes hosts as:
 #
 #    _combination my-accounts hosts-ports-users \
-#      ${options[-l]:+users=${options[-l]:q}} \
+#      ${opt_args[-l]:+users=${opt_args[-l]:q}} \
 #      hosts "$expl[@]"
 #
 #  This completes `host1', `host2', `mail-server', `news-server' and
@@ -31,7 +31,7 @@
 #  `_telnet' completes ports as:
 #
 #    _combination my-accounts hosts-ports-users \
-#      ${options[-l]:+users=${options[-l]:q}} \
+#      ${opt_args[-l]:+users=${opt_args[-l]:q}} \
 #      hosts="${line[2]:q}" \
 #      ports "$expl[@]"
 #
diff -ru ../z.old/Completion/Base/_command_names Completion/Base/_command_names
--- ../z.old/Completion/Base/_command_names	Wed Dec 15 09:58:09 1999
+++ Completion/Base/_command_names	Wed Dec 15 10:34:55 1999
@@ -17,11 +17,11 @@
   [[ "$1" = - ]] && shift
 
   defs=( "$defs[@]"
-    'jobs:: _jobs'
     'builtins:builtin command:compadd - ${(@k)builtins}'
     'functions:shell function:compadd - ${(@k)functions}'
     'aliases:alias:compadd - ${(@k)aliases}'
     'reserved-words:reserved word:compadd - ${(@k)reswords}'
+    'jobs:: _jobs -t'
   )
 fi
 
diff -ru ../z.old/Completion/Base/_jobs Completion/Base/_jobs
--- ../z.old/Completion/Base/_jobs	Wed Dec 15 09:58:10 1999
+++ Completion/Base/_jobs	Wed Dec 15 15:50:57 1999
@@ -1,11 +1,14 @@
 #autoload
 
-local expl disp jobs job jids pfx='%' desc
+local expl disp jobs job jids pfx='%' desc how
 
 _tags jobs || return 1
 
-zstyle -t ":completion${curcontext}:jobs" prefix-needed &&
-    [[ "$PREFIX" != %* ]] && return 1
+if [[ "$1" = -t ]]; then
+  zstyle -t ":completion${curcontext}:jobs" prefix-needed &&
+      [[ "$PREFIX" != %* || compstate[nmatches] -eq 0 ]] && return 1
+  shift
+fi
 zstyle -t ":completion${curcontext}:jobs" prefix-hidden && pfx=''
 zstyle -t ":completion${curcontext}:jobs" verbose       && desc=yes
 
@@ -31,8 +34,12 @@
   done
 fi
 
-if zstyle -t ":completion${curcontext}:jobs" strings; then
-  local texts i text str tmp
+zstyle -s ":completion${curcontext}:jobs" numbers how
+
+if [[ "$how" = (yes|true|on|1) ]]; then
+  jobs=( "$jids[@]" )
+else
+  local texts i text str tmp num max=0
 
   # Find shortest unambiguous strings.
 
@@ -47,6 +54,7 @@
       text=""
     fi
     tmp=( "${(@M)texts:#${str}*}" )
+    num=1
     while [[ -n "$text" && $#tmp -ge 2 ]]; do
       str="${str} ${text%% *}"
       if [[ "$text" = *\ * ]]; then
@@ -55,14 +63,19 @@
         text=""
       fi
       tmp=( "${(@M)texts:#${str}*}" )
+      (( num++ ))
     done
 
+    [[ num -gt max ]] && max="$num"
+
     jobs=( "$jobs[@]" "$str" )
   done
 
-  [[ -n "$pfx" && -n "$desc" ]] && disp=( "${(@)disp#%}" )
-else
-  jobs=( "$jids[@]" )
+  if [[ "$how" = [0-9]## && max -gt how ]]; then
+    jobs=( "$jids[@]" )
+  else
+    [[ -z "$pfx" && -n "$desc" ]] && disp=( "${(@)disp#%}" )
+  fi
 fi
 
 if [[ -n "$desc" ]]; then
diff -ru ../z.old/Completion/Base/_tilde Completion/Base/_tilde
--- ../z.old/Completion/Base/_tilde	Wed Dec 15 09:58:10 1999
+++ Completion/Base/_tilde	Wed Dec 15 10:38:23 1999
@@ -4,7 +4,7 @@
 # for you or if there are too many of them, you may want to use
 # `compadd -qS/ - "$friends[@]"' or something like that.
 
-local expl suf dirs list lines revlines i ret disp
+local expl suf dirs list lines revlines i ret disp nm="$compstate[nmatches]"
 
 if [[ "$SUFFIX" = */* ]]; then
   ISUFFIX="/${SUFFIX#*/}$ISUFFIX"
@@ -23,7 +23,7 @@
 
   if _requested -V directory-stack expl 'directory stack' &&
      { ! zstyle -t ":completion${curcontext}:directory-stack" prefix-needed ||
-       [[ "$PREFIX" = [-+]* ]] }; then
+       [[ "$PREFIX" = [-+]* || nm -eq compstate[nmatches] ]] }; then
     if zstyle -t ":completion${curcontext}:directory-stack" verbose; then
       integer i
 
diff -ru ../z.old/Completion/Builtins/_cd Completion/Builtins/_cd
--- ../z.old/Completion/Builtins/_cd	Wed Dec 15 09:58:12 1999
+++ Completion/Builtins/_cd	Wed Dec 15 15:14:07 1999
@@ -39,7 +39,7 @@
   else
     _alternative \
         'local-directories:local directories:_path_files -/' \
-	'path-directories: directories in cdpath:_path_files -W \(${cdpath:#.}\) -/'
+	"path-directories: directories in cdpath:_path_files -W \\(${${(@)cdpath:#.}}\\) -/"
   fi
 else
   _path_files -/
diff -ru ../z.old/Completion/Builtins/_kill Completion/Builtins/_kill
--- ../z.old/Completion/Builtins/_kill	Wed Dec 15 09:58:13 1999
+++ Completion/Builtins/_kill	Wed Dec 15 10:36:19 1999
@@ -2,5 +2,5 @@
 
 _alternative \
     'signals:: _signals -p' \
-    'jobs:: _jobs' \
-    'processes:: _pids'
+    'processes:: _pids' \
+    'jobs:: _jobs -t'
diff -ru ../z.old/Completion/Builtins/_stat Completion/Builtins/_stat
--- ../z.old/Completion/Builtins/_stat	Wed Dec 15 09:58:13 1999
+++ Completion/Builtins/_stat	Wed Dec 15 10:42:35 1999
@@ -1,19 +1,19 @@
 #compdef stat
 
-local expl
+local expl ret=1
 
 if [[ "$words[CURRENT-1]" = -[AH] ]]; then
   _arrays
 else
-  _tags options files || return 1
+  _tags files options || return 1
 
   while _tags; do
+    _requested files && _files && ret=0
     _requested options expl 'inode element' &&
         { ! zstyle -t ":completion${curcontext}:options" prefix-needed ||
-          [[ "$PREFIX[1]" = + ]] } &&
+          [[ "$PREFIX[1]" = + || ret -eq 1 ]] } &&
         compadd "$expl[@]" - +device +inode +mode +nlink +uid +gid +rdev \
                              +size +atime +mtime +ctime +blksize +block +link
     fi
-    _requested files && _files
   done
 fi
diff -ru ../z.old/Completion/Builtins/_wait Completion/Builtins/_wait
--- ../z.old/Completion/Builtins/_wait	Wed Dec 15 09:58:14 1999
+++ Completion/Builtins/_wait	Wed Dec 15 10:36:40 1999
@@ -1,3 +1,3 @@
 #compdef wait
 
-_alternative 'jobs:: _jobs' 'processes:: _pids'
+_alternative 'processes:: _pids' 'jobs:: _jobs -t'
diff -ru ../z.old/Completion/Core/_path_files Completion/Core/_path_files
--- ../z.old/Completion/Core/_path_files	Wed Dec 15 09:58:19 1999
+++ Completion/Core/_path_files	Wed Dec 15 13:06:00 1999
@@ -4,7 +4,7 @@
 # to complete to `/usr/local/bin'.
 
 local linepath realpath donepath prepath testpath exppath
-local tmp1 tmp2 tmp3 tmp4 i orig pre suf tpre tsuf opre osuf cpre
+local tmp1 tmp2 tmp3 tmp4 i orig eorig pre suf tpre tsuf opre osuf cpre
 local pats haspats=no ignore group expl addpfx addsfx remsfx
 local nm=$compstate[nmatches] menu match matcher mopts atmp
 
@@ -108,6 +108,7 @@
 opre="$PREFIX"
 osuf="$SUFFIX"
 orig="${PREFIX}${SUFFIX}"
+eorig="$orig"
 
 [[ $compstate[insert] = (*menu|[0-9]*) || -n "$_comp_correct" ||
    ( $#compstate[pattern_match] -ne 0 &&
@@ -265,7 +266,11 @@
 	  if [[ "$tmp2[1]" = */* ]]; then
 	    tmp2=( "${(@)tmp2:h}" )
 	    compquote tmp2
-	    exppaths=( "$exppaths[@]" ${^tmp2}/${tpre}${tsuf} )
+	    if [[ "$tmp2" = */ ]]; then
+	      exppaths=( "$exppaths[@]" ${^tmp2}${tpre}${tsuf} )
+	    else
+	      exppaths=( "$exppaths[@]" ${^tmp2}/${tpre}${tsuf} )
+	    fi
           else
 	    exppaths=( "$exppaths[@]" ${tpre}${tsuf} )
 	  fi
@@ -453,7 +458,7 @@
 # expanded paths that are different from the string on the line, we add
 # them as possible matches.
 
-exppaths=( "${(@)exppaths:#$orig}" )
+exppaths=( "${(@)exppaths:#$eorig}" )
 
 if zstyle -t ":completion${curcontext}:paths" expand prefix &&
    [[ $#exppaths -gt 0 && nm -eq compstate[nmatches] ]]; then
diff -ru ../z.old/Completion/Core/_sort_tags Completion/Core/_sort_tags
--- ../z.old/Completion/Core/_sort_tags	Wed Dec 15 09:58:20 1999
+++ Completion/Core/_sort_tags	Wed Dec 15 15:15:11 1999
@@ -1,39 +1,28 @@
 #autoload
 
-local stags tag
+comptry arguments values
+comptry options
 
-if zstyle -a ":completion${curcontext}" sort-tags stags; then
+case "$curcontext" in
+# Some silly examples commented out:
+#
+# *::*p[bgpn]m:*)           # change the order for file-completion
+#   comptry globbed-files directories
+#   comptry all-files
+#   ;;
+# *::dvips::-o*)            # automatic context set by _arguments
+#   comptry all-files
+#   return
+#   ;;
+# *::kill:*)
+#   comptry processes
+#   return                  # this return ensures that we use only processes
+#   ;;
+*)
+  comptry globbed-files
+  comptry directories
+  comptry all-files
+  ;;
+esac
 
-  for tag in $stags; do
-    [[ $tag != '' ]] && comptry ${=tag}
-  done
-
-else
-
-  comptry arguments values
-  comptry options
-
-  case "$curcontext" in
-  # Some silly examples commented out:
-  #
-  # *::*p[bgpn]m:*)           # change the order for file-completion
-  #   comptry globbed-files directories
-  #   comptry all-files
-  #   ;;
-  # *::dvips::-o*)            # automatic context set by _arguments
-  #   comptry all-files
-  #   return
-  #   ;;
-  # *::kill:*)
-  #   comptry processes
-  #   return                  # this return ensures that we use only processes
-  #   ;;
-  *)
-    comptry globbed-files
-    comptry directories
-    comptry all-files
-    ;;
-  esac
-
-  comptry "$@"
-fi
+comptry "$@"
diff -ru ../z.old/Completion/Core/_tags Completion/Core/_tags
--- ../z.old/Completion/Core/_tags	Wed Dec 15 09:58:19 1999
+++ Completion/Core/_tags	Wed Dec 15 15:41:00 1999
@@ -4,7 +4,7 @@
 
   # We have arguments: the tags supported in this context.
 
-  local curcontext="$curcontext" order
+  local curcontext="$curcontext" order tag nodef
 
   if [[ "$1" = -C?* ]]; then
     curcontext="${curcontext}:${1[3,-1]}"
@@ -38,9 +38,24 @@
   _offered_tags=( "$_offered_tags[@]" "$@" )
   _last_tags=()
 
-  # Call the function that sorts the tags into sets.
+  # Sort the tags.
 
-  "${_sort_tags:-_sort_tags}" "$@"
+  if [[ -n "$_sort_tags" ]]; then
+    "$_sort_tags" "$@"
+  elif zstyle -a ":completion${curcontext}" tag-order order; then
+
+    for tag in $order; do
+      case $tag in
+      -)     nodef=yes;;
+      *\(\)) "${${tag%%[ 	]#\(\)}##[ 	]#}" "$@";;
+      ?*)    comptry ${=tag};;
+      esac
+    done
+
+    [[ -z "$nodef" ]] && comptry "$@"
+  else
+    comptry "$@"
+  fi
 
   # Return non-zero if at least one set of tags should be used.
 
diff -ru ../z.old/Completion/Core/compinit Completion/Core/compinit
--- ../z.old/Completion/Core/compinit	Wed Dec 15 09:58:19 1999
+++ Completion/Core/compinit	Wed Dec 15 15:41:56 1999
@@ -479,6 +479,8 @@
 zstyle ':completion:correct'  prompt        'correct to:'
 zstyle ':completion:*'        completer     '_complete'
 zstyle ':completion*:default' list-colors   no=0 fi=0 di=0 ln=0 pi=0 so=0 bd=0 cd=0 ex=0
+zstyle ':completion:*' tag-order 'arguments values' options \
+                                 globbed-files directories all-files
 
 # Now we automatically make the definition files autoloaded.
 
diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Wed Dec 15 09:57:54 1999
+++ Doc/Zsh/compsys.yo	Wed Dec 15 15:36:26 1999
@@ -302,13 +302,11 @@
 matches, often multiple types of matches.  These types are represented as
 simple names called `tags'.  The completion system will decide internally
 what sort of tags are allowed; a list of the standard possibilities is given
-below.  The list of tags is passed as the arguments of the function
-(tt(_sort_tags)), which can then determine the order in which the  tags are
-to be used by the completion function.  Only those types of matches whose
-tags were selected by the tt(_sort_tags) function will be produced, and in
-the order given.  Instead of altering tt(_sort_tags), you may define
-a `tt(sort-tags)' style for the appropriate context, as described in the
-list of standard styles below.
+below.  To determine in which order the tags are to be used by the
+completion function, the `tt(tag-order)' style for the appropriate
+context may be set, as described in the list of standard styles below.
+Only those types of matches whose tags were selected by this style
+will be produced, and in the order given.
 
 The tt(_complete_help) bindable command described in 
 ifzman(the section `Bindable Commands' below)\
@@ -317,8 +315,8 @@
 point in completion.  It shows a list of context names and the 
 tag names used in those contexts if completion were tried at the
 current cursor position.  Hence one can easily find out all the
-information needed to change the behaviour of the tt(_sort_tags) function
-or the tt(sort_tags) style for a particular context.
+information needed to change the behaviour of the tt(tag-order) style
+for a particular context.
 
 Completion behaviour can be modified by various other
 `styles' defined with the tt(zstyle) builtin command
@@ -756,9 +754,9 @@
 .
 )
 item(tt(glob))(
-Like tt(complete), this is used by the tt(_expand) completer.
+Like tt(completions), this is used by the tt(_expand) completer.
 
-The value is used like the one for tt(complete) and if it evaluates to 
+The value is used like the one for tt(completions) and if it evaluates to 
 `tt(1)', globbing will be attempted on the words resulting from
 substitution (see the tt(substitute) style) or the original string
 from the line.
@@ -819,7 +817,7 @@
 
 Note that the matches will still be completed, they are just not shown 
 in the list. To avoid having matches considered as possible
-completions at all the tt(_sort_tags) function can be modified as described
+completions at all the tt(tag-order) style can be modified as described
 below.
 )
 item(tt(hosts))(
@@ -1012,6 +1010,15 @@
 appears.  With tt(_oldlist), it will instead continue to cycle through the
 list of completions.
 )
+item(tt(numbers))(
+This is used with the tt(jobs) tag. If it is `true', the completions
+will use the job numbers instead of the shortest unambiguous strings
+of the jobs' command lines. If the value is a number, job numbers will 
+only be used if for at least one of the jobs that many (or more) words 
+from the command line string have to be used to make the strings
+unambiguous. E.g. if it is set to `tt(1)', strings will only be used
+if all jobs differ in the first word on their command lines.
+)
 item(tt(original))(
 This is used by the tt(_approximate), tt(_correct) and tt(_match)
 completers. The first two use it to decide if the original string should
@@ -1096,10 +1103,9 @@
 as single strings (not in the string containing all possible
 expansions).
 )
-item(tt(sort-tags))(
+item(tt(tag-order))(
 This provides a mechanism for sorting how the tags available in a
-particular context will be used.  It assumes you have not redefined the
-standard tt(_sort_tags) function.
+particular context will be used.
 
 The values for the style are sets of space-separated lists of tags.
 The tags in each value will be tried at the same time; if no match is
@@ -1108,18 +1114,27 @@
 For example,
 
 example(
-  zstyle :completion:complete::gunzip: sort-tags \ 
+  zstyle :completion:complete::gunzip: tag-order \ 
     'globbed-files directories' all-files
 )
 
 specifies that, when completing arguments of the command tt(gunzip),
 files generated by patterns (in this case, those ending in tt(.gz)) and
 any directories will be presented first, and if that fails, any other files
-will be tried.  If no valid tags are present, nothing will be completed. so
-this can be used to turn off completion in a particular context.
+will be tried.  If any string in the value consists of only a hyphen
+(`tt(-)'), then only the tags selected by the other strings will be
+generated. Normally all tags not explicitly selected will be tried at
+the end if the selected tags did not generate any matches.  This means 
+that a value of only one hyphen turns off completion in a particular
+context.
+
+Strings in the value may also be of the form `var(func)tt(())'. In
+this case the function var(func) will be called which can then define
+in which order tags are to be used based on additional context
+information. See the tt(_sort_tags) function below for a description
+of how such functions can be implemented.
 
-If no style has been defined for a context, the tt(_sort_tags) function
-provides defaults, as given below.
+If no style has been defined for a context, all tags will be used.
 )
 item(tt(special-dirs))(
 Normally, the completion code will not produce the directory names
@@ -1133,11 +1148,6 @@
 and it will stop when the last match is inserted. If this style is set
 to tt(verbose) a message will be displayed when the last match is reached.
 )
-item(tt(strings))(
-This is used with the tt(jobs) tag. If it is `true', the completions
-will use the shortest unambiguous strings of the jobs' command lines
-instead of the job numbers.
-)
 item(tt(substitute))(
 If this is unset or set to the empty string, the tt(_expand) completer
 will first try to expand all substitutions in the string (such as
@@ -1399,7 +1409,7 @@
 adding the original string from the line. In which order these strings 
 are generated and which of these strings are generated at all can be
 controlled by using the tt(group-order) style and by modifying the
-tt(sort-tags) style or tt(_sort_tags) function, as usual.
+tt(tag-order) style, as usual.
 
 The format string for tt(all-expansions) and for tt(expansions) may
 contain the sequence `tt(%o)' which will be replaced by the original
@@ -1642,7 +1652,7 @@
 If called with arguments, these are taken as the names of the tags for 
 the types of matches the calling completion function can generate in
 the current context. These tags are stored internally and sorted by
-calling the tt(_sort_tags) function. Following calls to this function
+using the tt(tag-order) style. Following calls to this function
 without arguments from the same function will then select the first,
 second, etc. set of tags requested by the user. To test if a certain
 tag should be tried, the tt(_requested) function has to be called (see 
@@ -1654,10 +1664,9 @@
 This function also accepts the tt(-C) option followed by a
 var(name). This name is temporarily (i.e. not visible outside
 tt(_tags)) appended (with a colon before it) to the contents of the
-tt(curcontext) parameter. This allows to make tt(_tags) and
-tt(_sort_tags) use a more specific context name without having to
-change and reset the tt(curcontext) parameter (which would otherwise
-have the same effect).
+tt(curcontext) parameter. This allows to make tt(_tags) use a more
+specific context name without having to change and reset the
+tt(curcontext) parameter (which would otherwise have the same effect).
 )
 findex(_requested)
 item(tt(_requested) [ tt(-12VJ) ] var(tag) var(name) var(descr) [ var(specs) ... ])(
@@ -2313,12 +2322,10 @@
 )
 findex(_sort_tags)
 item(tt(_sort_tags) var(tag) ...)(
-As described above, this may be redefined by the user, although a default
-implementation is provided.  In most cases, you will probably find it
-easier to define a tt(sort-tags) style for the context whose behaviour you
-wish to alter.
+As described above for the tt(tag-order) style, this is only provided
+to show how functions that sort tags can be implemented.
 
-Inside the tt(_sort_tags) function the name of the current context can
+Inside such functions the name of the current context can
 be accessed using the tt(curcontext) parameter. For example, the
 function generating file names (called tt(_files)) in the completion
 system is often called to generate only filenames matching a given
@@ -2357,7 +2364,7 @@
 any matches, names of directories are generated, and if that doesn't
 yield any matching names either, all filenames will be generated.
 
-In every context the tt(_sort_tags) function may call tt(comptry) as
+In every context the function may call tt(comptry) as
 often as it wants. Also, every string may be given as argument, even
 if no tag with such a name was offered by the completion
 function. This allows one to give a preferred ordering for some common 
@@ -2365,7 +2372,7 @@
 names. For example, many completion functions can generate both
 arguments and option names for commands. These functions normally use
 the tags tt(arguments) and tt(options). Depending on your preference
-you may write in your tt(_sort_tags) function:
+you may write in your sorting function:
 
 example(_sort_tags() {
   comptry arguments options
@@ -2395,8 +2402,8 @@
 Since the completion functions are free to choose the tag names they
 use, there can't be a complete list. So to make sure that all types of 
 matches are eventually tried as completions, one should  use a call to 
-tt(comptry) with all arguments at the end of tt(_sort_tags). For those
-contexts where one really wants to make sure that certain tags are
+tt(comptry) with all arguments at the end of the sorting function. For
+those contexts where one really wants to make sure that certain tags are
 never used one can then use a call to tt(return) to circumvent that
 last tt(comptry). For example:
 
@@ -2419,30 +2426,6 @@
 tt(processes) tag in a call to tt(comptry). The immediate call to
 tt(return) then makes sure that the default tt(comptry) at the end is
 not executed.
-
-The default implementation of tt(_sort_tags) is the following:
-
-example(_sort_tags() {
-  local stags tag
-
-  if zstyle -a ":completion${curcontext}" sort-tags stags; then
-    for tag in $stags; do
-      [[ $tags != '' ]] && comptry ${=tag}
-    done
-
-  else		   
-    comptry arguments values
-    comptry options
-    case "$curcontext" in
-      (*) comptry globbed-files
-  	  comptry directories
-  	  comptry all-files
-          ;;
-    esac
-    comptry "$@"
-  fi
-})
-
 )
 
 enditem()
diff -ru ../z.old/Src/Makemod.in Src/Makemod.in
--- ../z.old/Src/Makemod.in	Wed Dec 15 09:57:40 1999
+++ Src/Makemod.in	Wed Dec 15 15:08:14 1999
@@ -7,12 +7,12 @@
 dir_top = ..
 subdir = Src
 
-MODOBJS = modobjs.zsh
+MODOBJS =
 MODULES =
-MDDS    = zsh.mdd
-MDHS    = zsh.mdh
-PROTOS  = proto.zsh
-SUBDIRS = Builtins Modules Zle
+MDDS    =
+MDHS    =
+PROTOS  =
+SUBDIRS =
 
 ENTRYOBJ = $(dir_src)/modentry..o
 NNTRYOBJ =
@@ -151,20 +151,7 @@
 uninstall.modules: uninstall.modules-here
 
 install.bin-here uninstall.bin-here:
-
-install.modules-here:
-	modules='$(MODULES)'; \
-	if test -n "$$modules"; then $(sdir_top)/mkinstalldirs $(DESTDIR)$(MODDIR); fi; \
-	for mod in $$modules; do \
-	    $(INSTALL_PROGRAM) $$mod $(DESTDIR)$(MODDIR)/$$mod; \
-	done
-
-uninstall.modules-here:
-	modules='$(MODULES)'; for mod in $$modules; do \
-	    if test -f $(DESTDIR)$(MODDIR)/$$mod; then \
-		rm -f $(DESTDIR)$(MODDIR)/$$mod; \
-	    else :; fi; \
-	done
+install.modules-here uninstall.modules-here:
 
 # ========== DEPENDENCIES FOR CLEANUP ==========
 
@@ -213,140 +200,5 @@
 
 $(dir_src)/modules-bltin:
 	@cd $(dir_src) && $(MAKE) $(MAKEDEFS) modules-bltin
-
-##### ===== DEPENDENCIES GENERATED FROM zsh.mdd ===== #####
-
-MODOBJS_zsh = builtin.o compat.o cond.o exec.o glob.o hashtable.o hist.o init.o input.o jobs.o lex.o linklist.o loop.o math.o mem.o module.o options.o params.o parse.o pattern.o prompt.o signals.o signames.o subst.o text.o utils.o watch.o
-MODDOBJS_zsh = builtin..o compat..o cond..o exec..o glob..o hashtable..o hist..o init..o input..o jobs..o lex..o linklist..o loop..o math..o mem..o module..o options..o params..o parse..o pattern..o prompt..o signals..o signames..o subst..o text..o utils..o watch..o  $(@E@NTRYOBJ)
-SYMS_zsh = builtin.syms compat.syms cond.syms exec.syms glob.syms hashtable.syms hist.syms init.syms input.syms jobs.syms lex.syms linklist.syms loop.syms math.syms mem.syms module.syms options.syms params.syms parse.syms pattern.syms prompt.syms signals.syms signames.syms subst.syms text.syms utils.syms watch.syms 
-EPRO_zsh = builtin.epro compat.epro cond.epro exec.epro glob.epro hashtable.epro hist.epro init.epro input.epro jobs.epro lex.epro linklist.epro loop.epro math.epro mem.epro module.epro options.epro params.epro parse.epro pattern.epro prompt.epro signals.epro signames.epro subst.epro text.epro utils.epro watch.epro
-INCS_zsh = $(EPRO_zsh) 
-EXPIMP_zsh =  $(EXPOPT)zsh.export
-NXPIMP_zsh =
-
-proto.zsh: $(EPRO_zsh)
-$(SYMS_zsh): $(PROTODEPS)
-
-zsh.export: $(SYMS_zsh)
-	( echo '#!'; cat $(SYMS_zsh) | sed -n '/^X/{s/^X//;p;}' | sort -u ) > $@
-
-modobjs.zsh: $(MODOBJS_zsh)
-	echo '' $(MODOBJS_zsh) >> $(dir_src)/stamp-modobjs.tmp
-
-zsh.mdhi: zsh.mdhs $(INCS_zsh)
-	@test -f $@ || echo 'do not delete this file' > $@
-
-zsh.mdhs: zsh.mdd
-	@$(MAKE) -f $(makefile) $(MAKEDEFS) zsh.mdh.tmp
-	@if cmp -s zsh.mdh zsh.mdh.tmp; then \
-	    rm -f zsh.mdh.tmp; \
-	    echo "\`zsh.mdh' is up to date."; \
-	else \
-	    mv -f zsh.mdh.tmp zsh.mdh; \
-	    echo "Updated \`zsh.mdh'."; \
-	fi
-	echo 'timestamp for zsh.mdh against zsh.mdd' > $@
-
-zsh.mdh:  ../config.h system.h zsh.h sigcount.h signals.h prototypes.h hashtable.h ztype.h  zsh.mdhi
-	@$(MAKE) -f $(makefile) $(MAKEDEFS) zsh.mdh.tmp
-	@mv -f zsh.mdh.tmp zsh.mdh
-	@echo "Updated \`zsh.mdh'."
-
-zsh.mdh.tmp:
-	@( \
-	    echo '#ifndef have_zsh_module'; \
-	    echo '#define have_zsh_module'; \
-	    echo; \
-	    echo '/* Extra headers for this module */'; \
-	    for hdr in ../config.h system.h zsh.h sigcount.h signals.h prototypes.h hashtable.h ztype.h; do \
-		if test -f $$hdr; then \
-		    echo '# include "'$$hdr'"'; \
-		else \
-		    echo '# include "$(sdir)/'$$hdr'"'; \
-		fi; \
-	    done; \
-	    echo; \
-	    for epro in $(EPRO_zsh); do \
-		echo '# include "'$$epro'"'; \
-	    done; \
-	    echo; \
-	    echo '#endif /* !have_zsh_module */'; \
-	) > $@
-
-$(MODOBJS_zsh) $(MODDOBJS_zsh): zsh.mdh
-
-@CONFIG_MK@
-
-signames.c: signames1.awk signames2.awk ../config.h @SIGNAL_H@
-	$(AWK) -f $(sdir)/signames1.awk @SIGNAL_H@ >sigtmp.c
-	$(CPP) sigtmp.c >sigtmp.out
-	$(AWK) -f $(sdir)/signames2.awk sigtmp.out > $@
-	rm -f sigtmp.c sigtmp.out
-
-sigcount.h: signames.c
-	grep 'define.*SIGCOUNT' signames.c > $@
-
-init.o: bltinmods.list zshpaths.h zshxmods.h
-
-params.o: version.h
-
-version.h: $(sdir_top)/Config/version.mk
-	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@
-
-zshpaths.h: Makemod $(CONFIG_INCS)
-	@echo '#define MODULE_DIR "'$(MODDIR)'"' > zshpaths.h.tmp
-	@if test x$(fndir) != xno; then \
-	  echo '#define FPATH_DIR "'$(fndir)'"' >> zshpaths.h.tmp; \
-	  if test x$(FUNCTIONS_SUBDIRS) != x -a \
-	  x$(FUNCTIONS_SUBDIRS) != xno; then \
-	    fpath_tmp="`for f in $$FUNCTIONS_INSTALL; do \
-	      echo $$f | sed s%/.*%%; \
-	    done | sort | uniq`"; \
-	    fpath_tmp="`echo $$fpath_tmp | sed 's/ /\", \"/g'`"; \
-	    echo "#define FPATH_SUBDIRS { \"$$fpath_tmp\" }" \
-	    >>zshpaths.h.tmp; \
-	  fi; \
-	fi
-	@if cmp -s zshpaths.h zshpaths.h.tmp; then \
-	    rm -f zshpaths.h.tmp; \
-	    echo "\`zshpaths.h' is up to date." ; \
-	else \
-	    mv -f zshpaths.h.tmp zshpaths.h; \
-	    echo "Updated \`zshpaths.h'." ; \
-	fi
-
-bltinmods.list: modules.stamp modules-bltin xmods.conf mkbltnmlst.sh
-	srcdir='$(sdir)' MODBINS='modules-bltin' \
-	XMODCF='$(sdir)/xmods.conf' $(SHELL) $(sdir)/mkbltnmlst.sh $@
-
-zshxmods.h: modules-bltin xmods.conf
-	@echo "Creating \`$@'."
-	@( \
-	    binmods=`sed 's/^/ /;s/$$/ /' modules-bltin`; \
-	    for mod in `cat $(sdir_src)/xmods.conf`; do \
-		case $$binmods in \
-		    *" $$mod "*) \
-			echo "#define    LINKED_XMOD_$$mod 1" ;; \
-		    *)  echo "#ifdef DYNAMIC"; \
-			echo "# define UNLINKED_XMOD_$$mod 1"; \
-			echo "#endif" ;; \
-		esac; \
-	    done; \
-	    echo; \
-	    for mod in $$binmods; do \
-		echo "int boot_$$mod _((Module));"; \
-	    done; \
-	) > $@
-
-clean-here: clean.zsh
-clean.zsh:
-	rm -f sigcount.h signames.c bltinmods.list version.h zshpaths.h zshxmods.h
-
-# This is not properly part of this module, but it is built as if it were.
-main.o: main.c zsh.mdh main.epro
-	$(CC) -c -I. $(CPPFLAGS) $(DEFS) $(CFLAGS) -o $@ $(sdir)/main.c
-
-main.syms: $(PROTODEPS)
-proto.zsh: main.epro
 
 ##### End of Makemod.in

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


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

* PATCH: cleanup
@ 1999-12-09 10:35 Sven Wischnowsky
  0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 1999-12-09 10:35 UTC (permalink / raw)
  To: zsh-workers


This is mostly cleanup for the docs, but reading that made me notice
some things that needed fixing in the completion functions, too:

- Of course, _description (and friends) should get the optional `1' or 
  `2' in the option before the `J' or `V'.
- The utility functions should support the -1, -2, and -n options.

And a question that came to mind: does anyone use the _menu or _list
completers? If not, we should probably remove them, or at least _menu
because that's made superfluous by the menu style (which should be far 
better than _menu ever was).

Another question is whether we should at least try to group the styles 
in some sensible way. Probably even using subsections. Opinions?

Bye
 Sven

diff -ru ../z.old/Completion/Core/_description Completion/Core/_description
--- ../z.old/Completion/Core/_description	Thu Dec  9 09:19:47 1999
+++ Completion/Core/_description	Thu Dec  9 11:21:15 1999
@@ -5,12 +5,9 @@
 gropt=(-J)
 hide=()
 
-if [[ "$1" = -[VJ] ]]; then
+if [[ "$1" = -([12]|)[VJ] ]]; then
   gropt=("$1")
   shift
-elif [[ "$1" = -[VJ] ]]; then
-  gropt=("-${1[3,-1]}" "${1[1,2]}")
-  shift
 fi
 
 _lastdescr=( "$_lastdescr[@]" "$3" )
@@ -20,6 +17,7 @@
 name="$2"
 
 _style -s "$1" format format || _style -s descriptions format format
+
 _style -s "$1" hidden hidden
 if [[ "$hidden" = (all|yes|true|1|on) ]]; then
   [[ "$hidden" = all ]] && format=''
diff -ru ../z.old/Completion/Core/_files Completion/Core/_files
--- ../z.old/Completion/Core/_files	Thu Dec  9 09:19:47 1999
+++ Completion/Core/_files	Thu Dec  9 11:23:35 1999
@@ -4,13 +4,13 @@
 
 opts=()
 group=()
-while getopts "P:S:qr:R:W:F:J:V:X:f/g:M:" opt; do
+while getopts "P:S:qr:R:W:F:J:V:X:f/g:M:12n" opt; do
   case "$opt" in
-  /)    [[ "$type" = file       ]] && type=dir       ;;
-  g)    [[ "$type" = (file|dir) ]] && type="$OPTARG" ;;
-  q)    opts=("$opts[@]" -q               )          ;;
-  [JV]) group=(          "-$opt" "$OPTARG")          ;;
-  [^f]) opts=("$opts[@]" "-$opt" "$OPTARG")          ;;
+  /)      [[ "$type" = file       ]] && type=dir       ;;
+  g)      [[ "$type" = (file|dir) ]] && type="$OPTARG" ;;
+  [qn12]) opts=("$opts[@]" "-$opt"          )          ;;
+  [JV])   group=(          "-$opt" "$OPTARG")          ;;
+  [^f])   opts=("$opts[@]" "-$opt" "$OPTARG")          ;;
   esac
 done
 
diff -ru ../z.old/Completion/Core/_main_complete Completion/Core/_main_complete
--- ../z.old/Completion/Core/_main_complete	Thu Dec  9 09:19:47 1999
+++ Completion/Core/_main_complete	Thu Dec  9 11:20:51 1999
@@ -136,11 +136,10 @@
   fi
 fi
 
-_style -s warnings format format
-
 if [[ compstate[nmatches] -eq 0 &&
       compstate[matcher] -eq compstate[total_matchers] &&
-      -n "$format" && $#_lastdescr -ne 0 ]]; then
+      $#_lastdescr -ne 0 ]] &&
+   _style -s warnings format format; then
   local str
 
   compstate[list]='list force'
diff -ru ../z.old/Completion/Core/_multi_parts Completion/Core/_multi_parts
--- ../z.old/Completion/Core/_multi_parts	Thu Dec  9 09:19:48 1999
+++ Completion/Core/_multi_parts	Thu Dec  9 11:26:36 1999
@@ -17,15 +17,15 @@
 expl=()
 opts=()
 sopts=()
-while getopts "J:V:X:P:S:r:R:qM:" opt; do
+while getopts "J:V:X:P:S:r:R:qM:12n" opt; do
   case "$opt" in
-  [JV])  group=("-$opt" "$OPTARG");;
-  X)     expl=(-X "$OPTARG");;
-  P)     opts=( "$opts[@]" -P "$OPTARG")
-         sopts=( "$sopts[@]" -P "$OPTARG");;
-  [SrR]) sopts=( "$sopts[@]" -P "$OPTARG");;
-  q)     sopts=( "$sopts[@]" -q);;
-  M)     match="$OPTARG";;
+  [JV])   group=("-$opt" "$OPTARG");;
+  X)      expl=(-X "$OPTARG");;
+  P)      opts=( "$opts[@]" -P "$OPTARG")
+          sopts=( "$sopts[@]" -P "$OPTARG");;
+  [SrR])  sopts=( "$sopts[@]" -P "$OPTARG");;
+  [q12n]) sopts=( "$sopts[@]" "-$opt");;
+  M)      match="$OPTARG";;
   esac
 done
 shift OPTIND-1
diff -ru ../z.old/Completion/Core/_path_files Completion/Core/_path_files
--- ../z.old/Completion/Core/_path_files	Thu Dec  9 09:19:48 1999
+++ Completion/Core/_path_files	Thu Dec  9 11:24:45 1999
@@ -6,7 +6,7 @@
 local linepath realpath donepath prepath testpath exppath
 local tmp1 tmp2 tmp3 tmp4 i orig pre suf tpre tsuf opre osuf cpre
 local pats haspats=no ignore group expl addpfx addsfx remsfx
-local nm=$compstate[nmatches] menu match matcher
+local nm=$compstate[nmatches] menu match matcher mopts
 
 typeset -U prepaths exppaths
 
@@ -24,11 +24,14 @@
 remsfx=()
 expl=()
 matcher=()
+mopts=()
 
 # Get the options.
 
-while getopts "P:S:qr:R:W:F:J:V:X:f/g:M:" opt; do
+while getopts "P:S:qr:R:W:F:J:V:X:f/g:M:12n" opt; do
   case "$opt" in
+  [12n]) mopts=( "$mopts[@]" "-$opt" )
+         ;;
   P)     addpfx=(-P "$OPTARG")
          ;;
   S)     addsfx=(-S "$OPTARG")
@@ -347,13 +350,13 @@
       if [[ -n $menu ]] || ! _style paths expand '*suffix*'; then
         _style paths cursor && compstate[to_end]=''
         if [[ "$tmp3" = */* ]]; then
-	  compadd -Qf -p "$linepath$tmp4" -s "/${tmp3#*/}" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" -s "/${tmp3#*/}" \
 	          -W "$prepath$realpath$testpath" "$ignore[@]" \
 		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                   -M "r:|/=* r:|=* $match" "$group[@]" "$expl[@]" \
 		  - "${(@)tmp1%%/*}"
 	else
-	  compadd -Qf -p "$linepath$tmp4" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" \
 	          -W "$prepath$realpath$testpath" "$ignore[@]" \
 		   "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                    -M "r:|/=* r:|=* $match" "$group[@]" "$expl[@]" \
@@ -362,14 +365,14 @@
       else
         if [[ "$tmp3" = */* ]]; then
           for i in "$tmp1[@]"; do
-	    compadd -Qf -p "$linepath$tmp4" -s "/${i#*/}" \
+	    compadd -Qf "$mopts[@]" -p "$linepath$tmp4" -s "/${i#*/}" \
 		    -W "$prepath$realpath$testpath" "$ignore[@]" \
 		    "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                     -M "r:|/=* r:|=* $match" "$group[@]" "$expl[@]" \
 		    - "${i%%/*}"
 	  done
         else
-	  compadd -Qf -p "$linepath$tmp4" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" \
 		  -W "$prepath$realpath$testpath" "$ignore[@]" \
 		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                   -M "r:|/=* r:|=* $match" "$group[@]" "$expl[@]" \
@@ -419,7 +422,7 @@
     fi
     tmp4="$testpath"
     compquote tmp4 tmp1
-    compadd -Qf -p "$linepath$tmp4" \
+    compadd -Qf "$mopts[@]" -p "$linepath$tmp4" \
 	    -W "$prepath$realpath$testpath" "$ignore[@]" \
 	    "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
             -M "r:|/=* r:|=* $match" "$group[@]" "$expl[@]" \
@@ -437,7 +440,7 @@
    [[ $#exppaths -gt 0 && nm -eq compstate[nmatches] ]]; then
   PREFIX="${opre}"
   SUFFIX="${osuf}"
-  compadd -Q -S '' "$group[@]" "$expl[@]" \
+  compadd -Q "$mopts[@]" -S '' "$group[@]" "$expl[@]" \
           -M "r:|/=* r:|=* $match" -p "$linepath" - "$exppaths[@]"
 fi
 
diff -ru ../z.old/Completion/Core/_sep_parts Completion/Core/_sep_parts
--- ../z.old/Completion/Core/_sep_parts	Thu Dec  9 09:19:48 1999
+++ Completion/Core/_sep_parts	Thu Dec  9 11:25:54 1999
@@ -25,13 +25,13 @@
 group=()
 expl=()
 opts=()
-while getopts "J:V:X:P:S:r:R:qM:" opt; do
+while getopts "J:V:X:P:S:r:R:qM:12n" opt; do
   case "$opt" in
-  [JV]) group=("-$opt" "$OPTARG");;
-  X)    expl=(-X "$OPTARG");;
-  q)    opts=( "$opts[@]" -q );;
-  M)    match="$OPTARG";;
-  *)    opts=( "$opts[@]" "-$opt" "$OPTARG" );;
+  [JV])   group=("-$opt" "$OPTARG");;
+  X)      expl=(-X "$OPTARG");;
+  [q12n]) opts=( "$opts[@]" "-$opt" );;
+  M)      match="$OPTARG";;
+  *)      opts=( "$opts[@]" "-$opt" "$OPTARG" );;
   esac
 done
 shift OPTIND-1
diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Thu Dec  9 09:19:26 1999
+++ Doc/Zsh/compsys.yo	Thu Dec  9 11:08:58 1999
@@ -234,7 +234,7 @@
 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)'.
+containing the substring tt(patterns).
 
 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
@@ -267,7 +267,8 @@
 user. This function allows to define so-called styles that are used by 
 various completion functions. These styles are associated with
 patterns that are compared to context names used by the completion
-system. The configuration possibilities are explained in detail in
+system. The possible ways to configure the completion system are
+explained in detail in
 ifzman(the section `Completion System Configuration' below)\
 ifnzman(noderef(Completion System Configuration))\
 .
@@ -316,7 +317,7 @@
 completion system (see
 ifzman(the section `Control Functions' below)\
 ifnzman(noderef(Control Functions)) 
-for more information). And the tt(::dvips:) shows that we are
+for more information). The tt(::dvips:) shows that we are
 completing arguments for the tt(dvips) command. Such a doubled colon
 will appear only before and after the name of the command, but note
 that the second colon after the command name is really only added when 
@@ -344,8 +345,7 @@
 glob pattern and then uses the tags tt(globbed-files),
 tt(directories), and tt(all-files). This means that the function
 offers to generate filenames matching the pattern, names of
-directories or all filenames as possible matches. Now, if the user has
-this definition for tt(_sort_tags):
+directories or all filenames as possible matches. Example:
 
 example(_sort_tags() {
   case $curcontext in
@@ -451,8 +451,8 @@
 information needed to change the tt(_sort_tags) function when one
 wants to change the way matches are generated for that context.
 
-But the tt(_sort_tags) function is only one half of the configuration
-possibilities of the completion system. The other half uses the
+But the completion system can not only be configured by supplying a
+specialized tt(_sort_tags) function. There are also the
 `styles' defined with the tt(compstyle) function mentioned in
 ifzman(the section `Initialization' above)\
 ifnzman(noderef(Initialization))\
@@ -759,8 +759,10 @@
 that the values of several of these styles represent boolean
 values. In all these cases any of the strings `tt(true)', `tt(on)',
 `tt(yes)', and `tt(1)' can be used for the truth value `true' and
-every other value (or if the style is not set at all for the context
-in which it is looked up) stands for `false'.
+the strings `tt(false)', `tt(off)', `tt(no)', and `tt(0)' are
+interpreted as `false'.  The behavior for any other value is undefined 
+unless the description for the particular style mentions other
+possible values.
 
 startitem()
 item(tt(accept-exact))(
@@ -795,6 +797,19 @@
 ifzman(the section `Control Functions' below)\
 ifnzman(noderef(Control Functions))\
 .
+
+Note that the widget functions from the distribution that call the
+completion code (namely, the tt(incremental-complete-word) and the
+tt(predict-on) widgets) set up their top-level context name before
+calling completion. This allows one to define different sets of
+completer functions for normal completion and for these widgets. For
+example, to use completion, approximation and correction for normal
+completion, completion and correction for incremental completion and
+only completion for prediction one could use:
+
+example(compstyle '*' completer _complete _correct _approximate
+compstyle ':incremental' completer _complete _correct
+compstyle ':predict' completer _complete)
 )
 item(tt(completions))(
 This style is used by the tt(_expand) completer function.
@@ -822,7 +837,7 @@
 )
 item(tt(cursor))(
 This is used together with the tt(paths) tag by the function
-generating filenames as matches to find out if the cursor will be left
+generating filenames as matches to find out if the cursor should be left
 after the first ambiguous pathname component even when menucompletion
 is used.
 )
@@ -832,10 +847,17 @@
 generate only names of modified files in the appropriate places.
 )
 item(tt(expand))(
-Like tt(cursor), this style is used with the tt(paths) tag. If it is
-set to `true', the partially typed path from the line will be
-expanded as far as possible even if trailing pathname components can
-not be completed.
+Like tt(cursor), this style is used with the tt(paths) tag. If its
+value contains the string tt(prefix), the partially typed path from
+the line will be expanded as far as possible even if trailing pathname
+components can not be completed. If it contains the string tt(suffix)
+and normal (non-menu-) completion is used, matching names for
+components after the first ambiguous one will be added, too. This
+means that the resulting string is the longest unambiguous string
+possible, but if menucompletion is started on the list of matches
+generated this way (e.g. due to the option tt(AUTO_MENU) being set),
+this will also cycle through the names of the files in pathname
+components after the first ambiguous one.
 )
 item(tt(format))(
 If this is set for the tt(descriptions) tag, its value is used as a
@@ -845,11 +867,11 @@
 specify output attributes, such as `tt(%b)' and `tt(%s)'.
 
 For the same purpose, this style is also tested with the tags used
-when matches are generated em(before it is tested for the
-tt(descriptions) tag). This gives the possibility to define different
+when matches are generated before it is tested for the
+tt(descriptions) tag. This gives the possibility to define different
 format strings for different types of matches.
 
-Not also that some completer functions define additional
+Note also that some completer functions define additional
 `tt(%)'-sequences. These are described for the completer function that 
 make use of them.
 
@@ -893,7 +915,7 @@
 example(compstyle '*' group-name '')
 
 All matches for which no group name is defined will be put in a group
-named `tt(-default-)'.
+named tt(-default-).
 )
 item(tt(group-order))(
 This style is to be used together with the tt(group-name) style. Once
@@ -924,7 +946,7 @@
 displayed.
 
 Note that the matches will still be completed, they are just not shown 
-in the list. To avoid having some matches to considered possible
+in the list. To avoid having some matches to be considered possible
 completions one can modify the tt(_sort_tags) function as described
 above.
 )
@@ -956,7 +978,7 @@
 least as long as the original string from the line.
 )
 item(tt(last-prompt))(
-This is used to determine if thecompletion code should try to put the
+This is used to determine if the completion code should try to put the
 cursor back onto the previous command line after showing a completion
 listing (as for the tt(ALWAYS_LAST_PROMPT) option). Like several other 
 styles it is tested for the tt(default) tag and all tags used when
@@ -1056,7 +1078,7 @@
 so on, until either a match was found or the maximum number of errors
 given by this style has been reached.
 
-If the value for this style contains the string `tt(numeric)', the 
+If the value for this style contains the string tt(numeric), the 
 completer function will take any numeric argument as the
 maximum number of errors allowed. For example, with
 
@@ -1067,7 +1089,7 @@
 errors are accepted.  Hence with a value of `tt(0 numeric)', no correcting
 completion will be attempted unless a numeric argument is given.
 
-If the value contains the string `tt(not-numeric)', tt(_approximate)
+If the value contains the string tt(not-numeric), tt(_approximate)
 will em(not) try to generate corrected
 completions when given a numeric argument, so in this case the number given
 should be greater than zero.  For example, `tt(2 not-numeric)' specifies that
@@ -1082,22 +1104,24 @@
 are generated. If none of these values is defined for any of the tags
 used, but for at least one of these tags the value is the string
 tt(auto), this says that the same behavior as for the tt(AUTO_MENU)
-options should be used. Finally, if menu-completion is started by some 
+option should be used. Finally, if menucompletion is started by some 
 other means (e.g. by setting the tt(MENU_COMPLETE) option) and the
 value for one of the tags used is `false' (i.e. tt(no), tt(false),
-tt(0), or tt(off)), then menu-completion will em(not) be started for
+tt(0), or tt(off)), then menucompletion will em(not) be started for
 this completions. Note that the values defined for normal tags
 override the value set for the tt(default) tag.
 
 Either instead of or in addition to one of the values above, the value
 for this style may also contain the string tt(select), optionally
-followed by an equal sign and a number. In this case menu-selection
+followed by an equal sign and a number. In this case menuselection
 (as defined by the tt(computil) module) will be started. Without the
 optional number, it will be started unconditionally and with a number
 it will be started only if at least that many matches are generated
 (if the values for more than one tag defines such a number, the
-smallest one is taken). Starting menu-selection can explicitly be
-turned off by defining a value containing the string tt(no-select).
+smallest one is taken). Starting menuselection can explicitly be
+turned off by defining a value containing the string
+tt(no-select). Note that all this only works if the tt(complist)
+module is explicitly loaded by the user, though.
 
 This is also used by the tt(_oldlist) completer. Here it controls how menu
 completion behaves when a completion has already been inserted and the
@@ -1122,7 +1146,7 @@
 always be added.
 
 For the tt(_match) completer, if this style is set to
-`tt(only)', it will try to generate matches without inserting a
+tt(only), it will try to generate matches without inserting a
 `tt(*)' at the cursor position. If set to any other non-empty value,
 it will first try to generate matches without inserting the `tt(*)'
 and if that yields no matches, it will try again with the `tt(*)'
@@ -1140,7 +1164,9 @@
 
 Also, the function that completes color names uses this style with the 
 tt(colors) tag. Here, the value should be the pathname of a file
-containing color names in the format of an X11 tt(rgb.txt) file.
+containing color names in the format of an X11 tt(rgb.txt) file. That
+file (if it can be found) will be used as the default if the style is
+not set.
 )
 item(tt(ports))(
 A style holding the service names of ports to complete. If this is
@@ -1156,7 +1182,7 @@
 This, too, is used for matches with a common prefix. If it is set to
 `true' this common prefix has to be typed by the user to generate the
 matches. E.g. for options this means that the `tt(-)', `tt(+)', or
-`tt(--)' has to be on the line to make option names be completed at
+`tt(-)tt(-)' has to be on the line to make option names be completed at
 all.
 )
 item(tt(prompt))(
@@ -1172,12 +1198,12 @@
 matches (without the leading underscore). Finally, `tt(%n)' is
 replaced by the number of matches generated, `tt(%a)' is replaced by
 an empty string if the matches are in the normal set (i.e. the one
-without file names with one of the suffixes from the tt(fignore)
-array) and with `tt( -alt-)' if the matches are in the alternate set,
-and if the tt(list) style is set, `tt(%l)' is replaced by `tt(...)' if
-the list of matches is too long to fit on the screen and with an empty
-string otherwise. If tt(incremental_list) is not set or set to an
-empty string, `tt(%l)' will always be removed.
+without file names with one of the suffixes from the
+tt(ignored-suffixes) style) and with `tt( -alt-)' if the matches are
+in the alternate set, and if the tt(list) style is set, `tt(%l)' is
+replaced by `tt(...)' if the list of matches is too long to fit on the
+screen and with an empty string otherwise. If the tt(list) style is
+`false', `tt(%l)' will always be removed.
 )
 item(tt(remove-all-dups))(
 The tt(_history_complete_word) bindable command uses this to decide if 
@@ -1197,8 +1223,8 @@
 expansions).
 )
 item(tt(stop))(
-If set to a non-empty string, the tt(_history_complete_word) bindable
-command will always insert matches as if menu-completion were started
+If set to `true', the tt(_history_complete_word) bindable
+command will always insert matches as if menucompletion were started
 and it will stop when the last match is inserted. If this style is set
 to tt(verbose) a message will be displayed when the last match is reached.
 )
@@ -1230,7 +1256,7 @@
 The values of this style should be of the form
 `var(user)tt(:)var(host)'. It is used for commands that need pairs of
 user- and hostnames. For such commands, only the pairs from this style 
-are used and if, for example, the hostname is already typed, then only 
+are used and if, for example, the username is already typed, then only 
 the hostnames for which there is a pair with that username is defined.
 
 If set for the tt(my-accounts) tag, this is used for commands such as
@@ -1271,7 +1297,7 @@
 
 example(compstyle '*' completer _complete _correct)
 
-after sourcing tt(compinit). The default value for this style set up
+after calling tt(compinit). The default value for this style set up
 in tt(compinit) is `tt(_complete)', i.e. normally only ordinary
 completion is tried. The tt(_main_complete) function uses the return
 value of the completer functions to decide if other completers should be
@@ -1284,19 +1310,15 @@
 functions or by other ZLE widgets calling completion to register code
 that is to be executed after all matches have been added.
 
-The widget function tt(_main_complete) also uses the style 
-tt(last-prompt). If this is set to `true', the cursor is moved up
-to the last prompt after printing a list of matches even if a numeric
-argument was given.
-
 The following completer functions are contained in the distribution (users
 may write their own):
 
 cindex(completion system, completers)
 startitem()
+findex(_complete)
 item(tt(_complete))(
 This completer generates all possible completions in a context-sensitive
-manner, i.e. using the tt(compdef) function
+manner, i.e. using the settings defined with the tt(compdef) function
 explained above and the current settings of all special parameters.
 
 To complete arguments of commands, tt(_complete) uses the utility function
@@ -1341,13 +1363,13 @@
 (`tt(${...})').
 )
 item(tt(-first-))(
-for adding completions before any other other completion functions are
+for adding completions before any other completion functions are
 tried; if this
-function sets the tt(_compskip) parameter to `tt(all)', no other
+function sets the tt(_compskip) parameter to tt(all), no other
 completion functions will be called, if it is set to a string
-containing `tt(patterns)', no pattern completion functions will be
-called, and if it is set to a string containing `tt(default)' the
-function for the `tt(-default-)' context will not be called, but
+containing the string tt(patterns), no pattern completion functions
+will be called, and if it is set to a string containing tt(default)
+the function for the `tt(-default-)' context will not be called, but
 functions defined for commands will.
 )
 item(tt(-default-))(
@@ -1367,20 +1389,8 @@
 checks if the parameter `tt(compcontext)' is set to a non-empty
 value. If it is, the value is taken as the name of the context to use
 and the function defined for that context will be called.
-
-Note that the widget functions from the distribution that call the
-completion code (namely, the tt(incremental-complete-word) and the
-tt(predict-on) widgets) set up their top-level context name before
-calling completion. This allows one to define different sets of
-completer functions for normal completion and for these widgets. For
-example, to use completion, approximation and correction for normal
-completion, completion and correction for incremental completion and
-only completion for prediction one could use:
-
-example(compstyle '*' completer _complete _correct _approximate
-compstyle ':incremental' completer _complete _correct
-compstyle ':predict' completer _complete)
 )
+findex(_approximate)
 item(tt(_approximate))(
 This completer function uses the tt(_complete) completer to generate
 a list of strings for the context the cursor is currently in, allowing 
@@ -1406,7 +1416,7 @@
 
 This completer uses the tags tt(corrections) and tt(original) when
 generating the possible coprrections and the original string. The
-tt(format) style for the former may contain the additional seuqences
+tt(format) style for the former may contain the additional sequences
 `tt(%e)' and `tt(%o)' which will be replaced by the number of errors
 accepted to generate the corrections and the original string,
 respectively.
@@ -1418,6 +1428,7 @@
 first try the context name starts with `tt(:approximate:1)', on the
 second try with `tt(:approximate:2)', and so on.
 )
+findex(_correct)
 item(tt(_correct))(
 Generate corrections (but not completions) for the current word; this is
 similar to spell-checking.  This calls tt(_approximate) but uses a
@@ -1426,7 +1437,7 @@
 For example, with:
 
 example(compstyle '*' completer _complete _correct _approximate
-compstyle ':correct' accept 2 not-numeric'
+compstyle ':correct' accept 2 not-numeric
 compstyle ':approximate' accept 3 numeric)
 
 correction will accept up to two errors. If a numeric argument is
@@ -1442,6 +1453,7 @@
 tt(_approximate) will at least generate the corrected strings
 generated by the tt(_correct) completer -- and probably more.
 )
+findex(_match)
 item(tt(_match))(
 This completer is intended to be used after the tt(_complete)
 completer. It allows one to give patterns on the command line and
@@ -1452,7 +1464,7 @@
 Normally this will be done by taking the pattern from the line,
 inserting a `tt(*)' at the cursor position and comparing the resulting
 pattern with the possible completions generated. However, if the
-tt(original) style has a value of `tt(only)', no `tt(*)' will be
+tt(original) style has a value of tt(only), no `tt(*)' will be
 inserted. If tt(original) has any other non-empty string as its
 value, this completer will first try to generate matches without, then
 with a `tt(*)' inserted at the cursor position.
@@ -1465,6 +1477,7 @@
 Note that the matcher specifications defined globally or used by the
 completion functions will not be used.
 )
+findex(_expand)
 item(tt(_expand))(
 This completer function does not really do completion, but instead
 checks if the word on the command line is eligible for expansion and,
@@ -1490,6 +1503,7 @@
 In a different mode selected by the tt(completions) style, all
 em(completions) generated for the string on the line are inserted.
 )
+findex(_list)
 item(tt(_list))(
 This completer allows one to delay the insertion of matches until
 completion is attempted a second time without the word on the line
@@ -1498,6 +1512,7 @@
 ifzman(the section `Completion System Configuration' above)\
 ifnzman(noderef(Completion System Configuration)).
 )
+findex(_menu)
 item(tt(_menu))(
 This completer is a simple example function implemented to show how
 menucompletion can be done in shell code. It should be used as the
@@ -1507,6 +1522,7 @@
 menucompletion widgets such as tt(reverse-menu-complete), or
 tt(accept-and-menu-complete).
 )
+findex(_oldlist)
 item(tt(_oldlist))(
 This completer controls how the standard completion widgets behave
 when there is an existing list of completions which may have been
@@ -1529,6 +1545,7 @@
 following is a list of these and their default bindings.
 
 startitem()
+findex(_bash_completions)
 item(tt(_bash_completions))(
 This function is used by two widgets, tt(_bash_complete-word) and
 tt(_bash_list-choices).  It exists to provide compatibility with
@@ -1549,31 +1566,38 @@
 This includes the bindings for `tt(~)' in case they were already bound to
 something else; the completion code does not override user bindings.
 )
+findex(_correct_filename (^XC))
 item(tt(_correct_filename (^XC)))(
 Correct the filename path at the cursor position.  Allows up to six errors
 in the name.  Can also be called with an argument to correct
 a filename path, independently of zle; the correction is printed on
 standard output.
 )
+findex(_correct_word) (^Xc)
 item(tt(_correct_word) (^Xc))(
 Performs correction of the current argument using the usual contextual
 completions as possible choices. This uses the top-level context name
 `tt(:correct-word)' and then calls the tt(_correct) completer.
 )
+findex(_expand_word (^Xe))
 item(tt(_expand_word (^Xe)))(
 Performs expansion on the current word:  equivalent to the standard
 tt(expand-word) command, but using the tt(_expand) completer. Before
 calling it, the top-level context name is set to `tt(:expand-word)'.
 )
+findex(_history_complete_word) (\e/)
 item(tt(_history_complete_word) (\e/))(
-Complete words from the shell's command history.
+Complete words from the shell's command history. This uses the
+tt(list), tt(remove-all-dups), tt(sort), and tt(stop) styles.
 )
+findex(_most_recent_file (^Xm))
 item(tt(_most_recent_file (^Xm)))(
 Complete the name of the most recently modified file matching the pattern
 on the command line (which may be blank).  If given a numeric argument
 var(N), complete the var(N)th most recently modified file.  Note the
 completion, if any, is always unique.
 )
+findex(_read_comp (^X^R))
 item(tt(_read_comp (^X^R)))(
 Prompt the user for a string, and use that to perform completion on the
 current word.  There are two possibilities for the string.  First, it can
@@ -1597,6 +1621,7 @@
 existing string instead of reading a new one.  To force a new string to be
 read, call tt(_read_comp) with a numeric argument.
 )
+findex(_complete_help (^Xh))
 item(tt(_complete_help (^Xh)))(
 This widget displays information about the context names and tags used 
 when completing at the current cursor position.
@@ -1625,7 +1650,8 @@
 The return value of tt(_funcall) itself is zero if the function
 var(name) exists and was called and non-zero otherwise.
 )
-item(tt(_compalso))(
+findex(_compalso)
+item(tt(_compalso) var(names) ...)(
 This function looks up the definitions for the context and command
 names given as arguments and calls the handler functions for them if
 there is a definition (given with the tt(compdef) function). For
@@ -1633,6 +1659,7 @@
 `tt(_compalso -math-)' to include the completions generated for
 mathematical environments.
 )
+findex(_normal)
 item(tt(_normal))(
 This function is used for normal command completion.  If
 completion is attempted on the first word, command names are
@@ -1652,31 +1679,31 @@
 one can write a pattern completion function that keeps other functions 
 from being tried simply by setting this parameter to any value.
 )
-item(tt(_description))(
-The first three arguments to this function are: a group name,
-the name of an array and a string. It tests if some styles for the tag 
-and stores options usable for tt(compadd) in the array which guarantee 
-that the matches are generated as requested by the user. The styles
-tested are: tt(format) (which is first tested for the given tag and
-then for the tt(descriptions) tag if that isn't defined), tt(hidden)
-and tt(group-name) (the last two are tested only for the tag given as
-the first argument). This function also calls the tt(_setup) function
-which tests some more styles.
+findex(_description)
+item(tt(_description) [ tt(-12VJ) ] var(tag) var(name) var(descr) [ var(specs) ... ])(
+This function tests some styles for the var(tag) and and stores
+options usable for tt(compadd) in the array with the given var(name)
+which guarantee that the matches are generated as requested by the
+user. The styles tested are: tt(format) (which is first tested for the
+given tag and then for the tt(descriptions) tag if that isn't
+defined), tt(hidden) and tt(group-name) (the last two are tested only
+for the tag given as the first argument). This function also calls the
+tt(_setup) function which tests some more styles.
 
 The format string from the style (if any) will be modified so that the 
-sequence `tt(%d)' is replaced by the string given as the third
+sequence `tt(%d)' is replaced by the var(descr) given as the third
 argument. If tt(_description) is called with more than three
-arguments, these extra arguments should be of the form
+arguments, these var(specs) should be of the form
 `var(char)tt(:)var(str)' and every appearance of `tt(%)var(char)' in
 the format string will be replaced by var(string).
 
-These options placed in the array will also make sure that the matches
+The options placed in the array will also make sure that the matches
 are placed in a separate group, depending on the value of the
 tt(group-name) style. Normally a sorted group will be used for this
-(with the `tt(-J)' option), but if a option starting with `tt(-V)' or
-`tt(-J)' is given, that option will be included in the array, so that
-it is possible to make the group unsorted by giving the option
-`tt(-V)', `tt(-V1)', or `tt(-V2)'. 
+(with the `tt(-J)' option), but if a option starting with `tt(-V)',
+`tt(-J)', `tt(-1)', or `tt(-2)' is given, that option will be included
+in the array, so that it is possible to make the group unsorted by
+giving the option `tt(-V)', `tt(-1V)', or `tt(-2V)'. 
 
 In most cases, this function will be used like this:
 
@@ -1684,8 +1711,9 @@
 _description expl files file
 compadd "$expl[@]" - "$files[@]")
 )
-item(tt(_message))(
-This function takes one argument which is used like the second
+findex(_message)
+item(tt(_message) var(descr))(
+The var(descr) used like the third
 argument to the tt(_description) function. However, the resulting
 string will always be shown, not only if some matches were
 generated. This is useful to display help texts in places where no
@@ -1695,15 +1723,17 @@
 preference to the tt(format) style for the tt(descriptions) tag. The
 latter is used only if the former is unset.
 )
-item(tt(_setup))(
+findex(_setup)
+item(tt(_setup) var(tag))(
 This function expects a tag as its argument and sets up the special
 parameters used by the completion system appropriately for the tag,
 using styles such as tt(list-colors) and tt(last-prompt).
 
 Note that this function is called automatically from tt(_description)
-so that one normally don't have to call it explicitly.
+so that one normally doesn't have to call it explicitly.
 )
-item(tt(_tags))(
+findex(_tags)
+item(tt(_tags) [ tt(-C) var(name) [ var(tags) ... ] ])(
 If called with arguments, these are taken as the names of the tags for 
 the types of matches the calling completion function can generate in
 the current context. These tags are stored internally and sorted by
@@ -1716,14 +1746,16 @@
 The return value is zero if at least one of the tags is requested and
 non-zero otherwise. 
 
-This function also accepts the tt(-C) option followed by a name. This
-name is temporarily (i.e. not visible outside tt(_tags)) appended
-(with a colon before it) to the contents of the tt(curcontext)
-parameter. This allows to make tt(_tags) and tt(_sort_tags) use a
-more specific context name without having to change and reset the
-tt(curcontext) parameter (which would otherwise have the same effect).
+This function also accepts the tt(-C) option followed by a
+var(name). This name is temporarily (i.e. not visible outside
+tt(_tags)) appended (with a colon before it) to the contents of the
+tt(curcontext) parameter. This allows to make tt(_tags) and
+tt(_sort_tags) use a more specific context name without having to
+change and reset the tt(curcontext) parameter (which would otherwise
+have the same effect).
 )
-item(tt(_requested))(
+findex(_requested)
+item(tt(_requested) [ tt(-12VJ) ] var(tag) var(name) var(descr) [ var(specs) ... ])(
 A function that uses tt(_tags) to register tags and then calls it to
 loop over the requested sets of tags should call this function to
 check if a certain tag is currently requested. This normally has to be 
@@ -1743,9 +1775,7 @@
 non-zero otherwise).
 
 If more than one argument is given, tt(_requested) calls the
-tt(_description) function with all arguments and if the first argument 
-is a option string starting with tt(-J) or tt(-V), the argument after
-it is taken as the name of the tag.
+tt(_description) function with all arguments, including the options.
 This is often useful to do both the testing of the tag and
 getting the description for the matches one is about to add at
 once. E.g.:
@@ -1759,14 +1789,15 @@
   (( ret )) || break
 done)
 )
-item(tt(_wanted))(
+findex(_wanted)
+item(tt(_wanted) [ tt(-12VJ) ] var(tag) var(name) var(descr) [ var(specs) ... ])(
 In many contexts only one type of matches can be generated but even
 then it should be tested if the tag representing those matches is
 requested by the user. This function makes that easier.
 
 Like tt(_requested) it gets arguments as for tt(_description).
-With the tag it calls tt(_tags) and if that returns zero 
-(i.e. the tag is requested by the user) it calls tt(_description). So, 
+With the var(tag) it calls tt(_tags) and if that returns zero 
+(i.e. the var(tag) is requested by the user) it calls tt(_description). So, 
 if you want to offer only one tag and immediatly want to use the
 description built, you can just do:
 
@@ -1779,13 +1810,14 @@
 
 example(_tags tag && _helper)
 )
-item(tt(_alternative))(
+findex(_alternative)
+item(tt(_alternative) [ tt(-C) var(name) ] var(specs) ...)(
 This function is useful if you offer multiple tags and building the
 matches for them is easy enough. It basically implements a loop like
 the one described above.
 
 The tags to use and what to do if the tags are requested are described 
-using the arguments which are of the form:
+using the var(specs) which are of the form:
 `var(tag)tt(:)var(descr)tt(:)var(action)'. The var(tag)s are offered
 using tt(_tags) and if the tag is requested, the var(action) is
 executed with the given var(descr) (description). The var(action)s
@@ -1805,13 +1837,14 @@
 Like tt(_tags) this function supports the tt(-C) option to give an
 additional context name component.
 )
+findex(_style)
 item(tt(_style))(
 This function is used to look up the values of styles defined by the
 user. In its simplest form, it is called with two arguments: a tag and 
 a style-name. The tag (if non-empty) is temporarily appended to the
 current context name (preceded by a colon) and the patterns defined by 
 the user with the tt(compstyle) function will be compared to that
-combined name. If any of those pattern matches the name and the given
+combined name. If any of those patterns match the name and the given
 style is defined for it and its boolean value is `true' (i.e. its
 value is one of `tt(true)', `tt(on)', `tt(yes)', and `tt(1)'), tt(_style)
 returns zero and non-zero otherwise. If you want to test the style not 
@@ -1819,12 +1852,6 @@
 used as a pattern and tt(_style) returns zero if the pattern matches
 the value defined for the style.
 
-The tt(-t) and tt(-f) options can be used to test for slightly
-different interpretions of boolean values. If they are given with a
-tag and a style-name as arguments, the return value is zero only if
-the style is set and the value is equal (or, in case of then tt(-f)
-option: unequal) to one of the values mentioned above.
-
 If you want to retrieve the value defined for the style, you can use
 one of the options tt(-b) (to retrieve it as a boolean value, i.e. one 
 of tt(yes) or tt(no)), tt(-s) (to get it as a scalar, i.e. a string
@@ -1848,13 +1875,14 @@
 example(local tmp
 _style -a foo path tmp)
 
-In any case, the return value of this function is zero, if a
+In any case, the return value of this function is zero if a
 definition for the style was found and non-zero if no definition was
 found.
 )
-item(tt(_describe))(
+findex(_describe)
+item(tt(_describe) var(descr) var(name1) [ var(name2) ] var(opts) ... tt(-)tt(-) ...)(
 This function can be used to add options or values with descriptions
-as matches. The first argument is taken as a string to display above
+as matches. The var(descr) is taken as a string to display above
 the matches if the tt(format) style for the tt(descriptions) tag is set.
 
 After this one or two names of arrays followed by options to give
@@ -1870,16 +1898,17 @@
 `tt(-)tt(-)'. This allows one to display matches together that need
 to be added with different options for tt(compadd).
 
-Before the first argument, two options may be given. A `tt(-o)' says
+Before the first argument, the option `tt(-o)' may be given. It says
 that the matches added are option names. This will make tt(_describe)
-use the tt(prefix-hidden), tt(prefix-needed) and tt(description) styles
+use the tt(prefix-hidden), tt(prefix-needed) and tt(verbose) styles
 to find out if the strings should be added at all and if the
 descriptions should be shown. Without the `tt(-o)' option, only the
-tt(description) style is used.
+tt(verbose) style is used.
 )
-item(tt(_multi_parts))(
+findex(_multi_parts)
+item(tt(_multi_parts) var(sep) var(array))(
 This function gets two arguments: a separator character and an
-array.  As usual, the array may be either the
+array.  As usual, the var(array) may be either the
 name of an array parameter or a literal array in the form
 `tt(LPAR()foo bar)tt(RPAR())' (i.e. a list of words separated by white 
 space in parentheses). With these arguments, this function will
@@ -1891,9 +1920,11 @@
 tt(_path_files) function.
 
 Like other utility functions, this function accepts the `tt(-V)',
-`tt(-J)', `tt(-X)', `tt(-M)', `tt(-P)', `tt(-S)', `tt(-r)', `tt(-R)', and
-`tt(-q)' options and passes them to the tt(compadd) builtin.
+`tt(-J)', `tt(-1)', `tt(-2)', `tt(-n)', `tt(-X)', `tt(-M)', `tt(-P)',
+`tt(-S)', `tt(-r)', `tt(-R)', and `tt(-q)' options and passes them to
+the tt(compadd) builtin.
 )
+findex(_sep_parts)
 item(tt(_sep_parts))(
 This function gets as arguments alternating arrays and separators.
 The arrays specify completions for parts of strings to be separated by the
@@ -1903,10 +1934,13 @@
 complete the string  `tt(f)' to `tt(foo)' and the string `tt(b@n)' to
 `tt(bar@news)'.
 
-This function passes the `tt(-V)', `tt(-J)', `tt(-X)', `tt(-M)', `tt(-P)',
-`tt(-S)', `tt(-r)', `tt(-R)', and `tt(-q)' options and their arguments
-to the tt(compadd) builtin used to add the matches.
+This function passes the `tt(-V)', `tt(-J)', `tt(-1)', `tt(-2)',
+`tt(-n)', `tt(-X)', `tt(-M)', `tt(-P)', `tt(-S)', `tt(-r)', `tt(-R)',
+and `tt(-q)' options and their arguments to the tt(compadd) builtin
+used to add the matches.
 )
+findex(_path_files)
+findex(_files)
 item(tt(_path_files) and tt(_files))(
 The function tt(_path_files) is used throughout the shell code
 to complete filenames. It allows completion of partial paths. For
@@ -1923,41 +1957,25 @@
 Additionally, the `tt(-F)'
 option from the tt(compadd) builtin is supported, giving direct control
 over which filenames should be ignored. If no such option is given,
-the tt(fignore) parameter is used.
+the tt(ignored-suffixes) style is used.
 
 The function tt(_files) calls tt(_path_files) with all the arguments
 it was passed and, if that generated no matches, calls tt(_path_files) again
 without any tt(-g) or tt(-/) option, thus generating all filenames.
 
-These functions also accept the `tt(-J)', `tt(-V)', `tt(-X)',
-`tt(-M)', `tt(-P)', `tt(-S)', `tt(-q)', `tt(-r)', and `tt(-R)' options
-from the tt(compadd) builtin.
+These functions also accept the `tt(-J)', `tt(-V)', `tt(-1)',
+`tt(-2)', `tt(-n)', `tt(-X)', `tt(-M)', `tt(-P)', `tt(-S)', `tt(-q)',
+`tt(-r)', and `tt(-R)' options from the tt(compadd) builtin.
 
-Finally, the tt(_path_files) function supports two styles.
-startitem()
-item(tt(expand))(
-If this is set to a string containing `tt(prefix)', the partially
-typed path from the line will be expanded as far as possible even if
-trailing pathname components can not be completed. If it contains the
-substring `tt(suffix)' and normal (non-menu-) completion is used,
-matching names for components after the first ambiguous one will be
-added, too. This means that the resulting string is the longest
-unambiguous string possible, but if menu-completion is started on the
-list of matches generated this way (e.g. due to the option
-tt(AUTO_MENU) being set), this will also cycle through the names
-of the files in pathname components after the first ambiguous one.
-)
-item(tt(cursor))(
-If this is set to `true', the cursor will be left after the first
-ambiguous pathname component even when menucompletion is used.
-)
-enditem()
+Finally, the tt(_path_files) function  uses the styles tt(expand) and
+tt(cursor) with the tt(paths) tag.
 )
+findex(_parameters)
 item(tt(_parameters))(
-This should be used to complete parameter names if you need some of the
-extra options of tt(compadd). All arguments are passed unchanged to
-the tt(compadd) builtin.
+This should be used to complete parameter names. All arguments are
+passed unchanged to the tt(compadd) builtin.
 )
+findex(_options)
 item(tt(_options))(
 This can be used to complete option names. It uses a matching
 specification that ignores a leading `tt(no)', ignores underscores and 
@@ -1965,6 +1983,8 @@
 lower-case counterparts. All arguments passed to this function are
 propagated unchanged to the tt(compadd) builtin.
 )
+findex(_set_options)
+findex(_unset_options)
 item(tt(_set_options) and tt(_unset_options))(
 These functions complete only set or unset options, with the same
 matching specification used in the tt(_options) function.
@@ -1974,13 +1994,14 @@
 are used to store the option settings in effect before the completion
 widget locally sets the options it needs.
 )
-item(tt(_arguments))(
+findex(_arguments)
+item(tt(_arguments) var(specs) ...)(
 This function resides in the tt(Base) subdirectory of the example
 completion system because it is not used by the core system.
 
 This function can be used to complete words on the line by simply
 describing the arguments the command on the line gets. The description 
-is given as arguments to this function, with each argument describing
+is given as arguments to this function, with each var(spec) describing
 one option or normal argument of the command. The descriptions
 understood are:
 
@@ -2045,13 +2066,11 @@
 in one string with the option name, but may also be given as a
 separate argument after the option, a plus sign should be used
 instead. If the argument may be given as the next string or in same
-string as the option name but separated by it from an equal sign, a
+string as the option name but separated from it by an equal sign, a
 `tt(=)' should be used instead of the minus or plus sign.
 
 If the option may be given more than once, a star
-(`tt(*)') has to be added in front of the var(opt-spec) because
-otherwise it is not offered as a possible completion again if it is
-already on the line.
+(`tt(*)') has to be added in front of the var(opt-spec).
 
 An var(opt-spec) may also contain a list of other option names with
 which the option described is mutually exclusive. Such a list is given 
@@ -2064,7 +2083,7 @@
 
 Finally, the var(opt-spec) may contain a explanation string. This is
 given in brackets at the end, as in `tt(-q[query operation])'. The
-tt(description) style for the tt(options) tag is used to decide if these
+tt(verbose) style is used to decide if these
 explanation strings should be printed when options are listed. If no
 explanation string is given but the tt(auto-describe) style is
 set and only one argument is described for this var(opt-spec), the
@@ -2076,7 +2095,7 @@
 
 In each of the cases above, the var(action) says how the possible
 completions should be generated. In cases where only one of a fixed
-set of strings can be completed, these string can directly be given as 
+set of strings can be completed, these strings can directly be given as 
 a list in parentheses, as in `tt(:foo:(foo bar baz))'. Such a list in
 doubled parentheses, as in `tt(:foo:((a\:bar b\:baz)))' should contain 
 strings consisting of the string to complete followed by a colon
@@ -2226,14 +2245,10 @@
 option `tt(-s) var(pairs)' (again, after the `tt(-)tt(-)') can be used to
 describe option aliases. Each var(pair) consists of a pattern and a
 replacement. E.g. some tt(configure)-scripts describe options only as
-`tt(-)tt(-enable-foo)', but also accept `tt(disable-foo)'. To allow
+`tt(-)tt(-enable-foo)', but also accept `tt(-)tt(-disable-foo)'. To allow
 completion of the second form, one would use `tt(-s "LPAR()#-)tt(-enable-
 -)tt(-disable-RPAR()")'.
 
-Finally, this function uses the styles tt(description),
-tt(prefix-hidden) and tt(prefix-needed) with the tt(options) tag when
-generating option names as matches.
-
 Example:
 
 example(_arguments '-l+:left border:' \ 
@@ -2262,7 +2277,8 @@
 be completed. The last description says that all other arguments are
 `var(page numbers)' but does not give possible completions.
 )
-item(tt(_values))(
+findex(_values)
+item(tt(_values) var(specs) ...)(
 This is used to complete values (strings) and their arguments or
 lists of such values.
 
@@ -2300,7 +2316,7 @@
 specified so that it will not be completed automatically. The
 `tt((two))' at the beginning says that if the value `tt(one)' is on
 the line, the value `tt(two)' will not be  considered to be a possible
-completion any more. Finally, the last value (`tt(two)') is described
+completion anymore. Finally, the last value (`tt(two)') is described
 as `tt(another number)' and gets an optional argument decribed as
 `tt(second count)' which will be completed from the strings `tt(1)',
 `tt(2)', and `tt(3)'. The tt(_values) function will complete lists of
@@ -2312,8 +2328,7 @@
 the argument is completed.
 
 To decide if the descriptions for the values (not those for the
-arguments) should be printed, the style tt(description) for the
-tt(values) tag is used.
+arguments) should be printed, the tt(verbose) is used.
 
 One last difference to tt(_arguments) is that this function uses the
 associative array
@@ -2334,7 +2349,8 @@
 which case you have to make the parameter tt(curcontext) local instead 
 of tt(context) (as described above).
 )
-item(tt(_regex_arguments))(
+findex(_regex_arguments)
+item(tt(_regex_arguments) var(name) var(specs) ...)(
 This function is a compiler to generate a completion function.  The
 first argument specifies the name of generated function and rest arguments
 specifies a completion specification in the notation like regular
@@ -2396,16 +2412,17 @@
 )
 enditem()
 )
-item(tt(_combination))(
+findex(_combination)
+item(tt(_combination) [ tt(-s) var(spec) ] var(tag) var(style) var(specs) ... var(field) var(opts) ...)(
 This function is used to complete combinations of values such as pairs 
 of hostnames and usernames. The possible values will be taken from the 
-style whose name is given as the second argument. The first argument
-is the tag to use to do the lookup.
+var(style) whose name is given as the second argument. The first argument
+is the var(tag) to use to do the lookup.
 
-The style name should consist of multiple parts separated with
+The style name should consist of multiple parts separated by
 hyphens which are then used as fieldnames. Known values for such
 fields can be given after the second argument in arguments of the form 
-`var(fiels)tt(=)var(pattern)'. The first argument without a equal sign 
+`var(field)tt(=)var(pattern)'. The first argument without a equal sign 
 is taken as the name of the field for which completions should be
 generated.
 
@@ -2419,7 +2436,7 @@
 the strings from the style value are generated as possible matches.
 
 If no style with the given name is defined for the given tag but a
-function named with the name of the requestd field preceded by an
+function named with the name of the requested field preceded by an
 underscore is defined, that function will be called to generate the
 matches. This is also done if none of the strings in the value of the
 style match all the patterns given as arguments.
@@ -2427,7 +2444,7 @@
 If the same name is used for more than one field, in both the
 `var(field)tt(=)var(pattern)' and the argument that gives the field
 name to complete for, the number of the field (starting with one) may
-be given after the fieldname (separated from it by a colon).
+be given after the fieldname, separated from it by a colon.
 
 All arguments after the requested fieldname are given to the
 tt(compadd) used (when generating matches from the style value) and to 
@@ -2458,7 +2475,9 @@
 these files.
 )
 item(tt(Builtins))(
-Functions for completing arguments of shell builtin commands.
+Functions for completing arguments of shell builtin commands and
+utility functions for this (which are also used by functions from the
+tt(User) directory).
 )
 item(tt(User))(
 Functions for completing arguments of external commands and suites of
diff -ru ../z.old/Etc/completion-style-guide Etc/completion-style-guide
--- ../z.old/Etc/completion-style-guide	Thu Dec  9 09:19:30 1999
+++ Etc/completion-style-guide	Thu Dec  9 11:17:34 1999
@@ -81,9 +81,9 @@
   _wanted names expl 'name' && compadd "$expl[@]" alice bob
 
 Note that you can also give the `-J' and `-V' options with the
-optional `1' or `2' following them supported by `_description':
+optional `1' or `2' preceding them supported by `_description':
 
-  _wanted -V2 names expl 'name' && compadd ...
+  _wanted -2V names expl 'name' && compadd ...
 
 The more complicated case is where you can offer multiple types of
 matches. In this case the user should be able to say which types he
@@ -284,16 +284,16 @@
   compadd "$expl@]" - <matches ...>
 
 Note that this function also accepts `-V' und `-J', optionally (in the 
-same word) followed by `1' or `2' to describe the type of group you
+same word) preceded by `1' or `2' to describe the type of group you
 want to use. For example:
 
   _description tag expl '...'
-  compadd "$expl[@]" -V1 foo - ...    # THIS IS WRONG!!!
+  compadd "$expl[@]" -1V foo - ...    # THIS IS WRONG!!!
 
 is *not* the right way to use a unsorted group. Instead do the
 simpler:
 
-  _description -V1 tag expl '...'
+  _description -1V tag expl '...'
   compadd "$expl[@]" - ...
 
 and everything will work fine.
@@ -308,11 +308,11 @@
 explanation to the same function that is used to test if the tags are
 requested (again: see above). Just as a reminder:
 
-  _wanted [ -V[1,2] | -J[1,2] ] <tag> expl <descr>
+  _wanted [ -[1,2]V | -[1,2]J ] <tag> expl <descr>
 
 and
 
-  _requested [ -V[1,2] | -J[1,2] ] <tag> expl <descr>
+  _requested [ -[1,2]V | -[1,2]J ] <tag> expl <descr>
 
 is all you need to make your function work correctly with both tags
 and description at the same time.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


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

* Re: PATCH: cleanup
@ 1999-11-18 14:49 Sven Wischnowsky
  0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 1999-11-18 14:49 UTC (permalink / raw)
  To: zsh-workers


Adam Spiers wrote:

> Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> > The question is: is now the right time for such changes or should we
> > wait until we all have gotten used to the styles stuff?
> 
> I vote for doing it now.  There are probably more people who haven't
> changed over yet than have, and hence would benefit from not having to
> make two lots of changes in a short space of time.

Almost the same as how I felt... but I wasn't exact enough again: the
problem is that some of the things I don't like in the present state
were not implemented by me and some are not fully understood by
me -- and I'm always a reluctant to change code that is not from me
(yes, really!). So, I thought that I should wait a little bit longer
until at least some people here have gone through the stuff and can
help to decide what should be changed to what. Or decide on their own
(and build the patches).


Bye
 Sven

P.S.: You know that I'm sometimes not exactly slow -- I didn't plan to 
      wait weeks ;-)

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


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

* Re: PATCH: cleanup
  1999-11-18  9:52 Sven Wischnowsky
@ 1999-11-18 12:09 ` Adam Spiers
  0 siblings, 0 replies; 8+ messages in thread
From: Adam Spiers @ 1999-11-18 12:09 UTC (permalink / raw)
  To: zsh-workers

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> The question is: is now the right time for such changes or should we
> wait until we all have gotten used to the styles stuff?

I vote for doing it now.  There are probably more people who haven't
changed over yet than have, and hence would benefit from not having to
make two lots of changes in a short space of time.


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

* Re: PATCH: cleanup
@ 1999-11-18 10:03 Sven Wischnowsky
  0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 1999-11-18 10:03 UTC (permalink / raw)
  To: zsh-workers


I wrote:

> This contains mostly cleanups for the manual stuff.

Aargh! Wrong patch (that was right filename, wrong directory).

Bye
 Sven

diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- olddoc/Zsh/compsys.yo	Thu Nov 18 08:49:49 1999
+++ Doc/Zsh/compsys.yo	Thu Nov 18 09:38:20 1999
@@ -167,8 +167,8 @@
 tt(complist) module is loaded (see
 ifzman(zmanref(zshmodules))\
 ifnzman(noderef(The complist Module))\
-), the tt(menu-select) widget can be used, too.  If the option tt(-n) is
-also given, the bindings will not be used if the key is already bound (that
+), the tt(menu-select) widget can be used, too.  Note that the
+bindings will not be used if the key is already bound (that
 is, is bound to something other than tt(undefined-key)).
 
 The widget is then bound to all the var(key-sequences) given, if any: when
@@ -202,7 +202,7 @@
 enditem()
 
 Note that the tt(#) is part of the tag name and no white space is allowed
-after it.  The tt(#compdef) tags use the tt(compdef) function defined
+after it.  The tt(#compdef) tags use the tt(compdef) function described
 below; the main difference is that the name of the function is supplied
 implicitly.
 
@@ -256,7 +256,7 @@
 
 In each of the forms supporting it the tt(-a) option makes the
 var(function) autoloadable (exactly equivalent to
-tt(autoload )var(function)).
+tt(autoload -U )var(function)).
 )
 findex(compstyle)
 cindex(completion system, configuring)
@@ -273,7 +273,7 @@
 .
 
 In the first form a new var(style) is defined for a certain
-var(pattern), setting it the value given by the var(strings). If there 
+var(pattern), setting it to the value given by the var(strings). If there 
 was already a definition for the same var(pattern)/var(style) pair,
 only the value is changed.
 
@@ -288,15 +288,6 @@
 the tt(-L) option is given this is done in the form of calls to
 tt(compstyle).
 )
-findex(funcall)
-item(tt(funcall) var(return) var(name) [ var(args) ... ])(
-If a function var(name) exists, it is called with the arguments
-var(args). Unless it is the empty string or a single hyphen,
-var(return) is taken as the name of a parameter and the return status
-from the called function is stored in it.
-The return value of tt(funcall) itself is zero if the function
-var(name) exists and was called and non-zero otherwise.
-)
 enditem()
 
 texinode(Completion System Configuration)(Control Functions)(Initialization)(Completion System)
@@ -324,8 +315,8 @@
 to, say, correction, which can also be done using the function based
 completion system (see
 ifzman(the section `Control Functions' below)\
-ifnzman(noderef(Control Functions))\
- for more information).
+ifnzman(noderef(Control Functions)) 
+for more information).
 
 In many of the possible contexts the completion system can generate
 matches, and often it can generate multiple types of matches. Whenever 
@@ -333,9 +324,9 @@
 a utility function, telling it what types of matches can be
 generated. These types are represented as simple names calld
 `tags'. This utility function in turn calls another function
-(tt(_sort_tags)) and gives the list of tags to it as the positional
+(tt(_sort_tags)) and gives the list of tags to it as
 arguments. The function tt(_sort_tags) can then say in which order the 
-tags are to be used by the completion function. The function will then 
+tags are to be used by the completion function. The function will 
 only generate those types of matches whose tags were selected by the
 user's implementation of the tt(_sort_tags) function. And it will
 try to generate the different types of matches in the order in which
@@ -348,8 +339,8 @@
 glob pattern and then uses the tags tt(globbed-files),
 tt(directories), and tt(all-files). This means that the function
 offers to generate filenames matching the pattern, names of
-directories or all filenames as possible matches. Now, the user may
-have definition for tt(_sort_tags):
+directories or all filenames as possible matches. Now, if the user has
+this definition for tt(_sort_tags):
 
 example(_sort_tags() {
   case $curcontext in
@@ -367,13 +358,13 @@
 
 Every call to the tt(comptry) function (well, it's actually a builtin
 command defined by the tt(computil) module, but never mind) gives a
-set of tags to use. So, the first calls says which tags are to be used 
+set of tags to use. So, the first call says which tags are to be used 
 first. If there are no matches for those tags, the tags from the
 second call to tt(comptry) will be tried, and so on. In the example
 this means that for the tt(dvips) command on the first attempt the
 names of DVI files and directories will be generated (first call to
 tt(comptry)). If none of those names match the string from the command
-line the completion function will then generate all filenames as
+line the completion function will generate all filenames as
 possible matches (second call to tt(comptry)).
 
 For all other context names the second case-pattern matches, so that
@@ -394,7 +385,6 @@
 
 example(_sort_tags() {
   comptry arguments options
-
   case $curcontext in
   ...
   esac
@@ -405,7 +395,6 @@
 example(_sort_tags() {
   comptry arguments
   comptry options
-
   case $curcontext in
   ...
   esac
@@ -419,13 +408,13 @@
 hyphen the option names start with yourself to see the list of option
 names that can be completed.
 
-Since the completion function are free to choose the tag names they
+Since the completion functions are free to choose the tag names they
 use, there can't be a complete list. So to make sure that all types of 
 matches are eventually tried as completions, one should  use a call to 
-tt(comptry) with all positional argument at the end of
-tt(_sort_tags). For those contexts where one really wants to make sure 
-that certain tags are never used one can then use a call to tt(return) 
-to circumvent that last tt(comptry). For example:
+tt(comptry) with all arguments at the end of tt(_sort_tags). For those
+contexts where one really wants to make sure that certain tags are
+never used one can then use a call to tt(return) to circumvent that
+last tt(comptry). For example:
 
 example(_sort_tags() {
   ...
@@ -449,10 +438,10 @@
 
 The tt(_complete_help) bindable command described in 
 ifzman(the section `Bindable Commands' below)\
-ifnzman(noderef(Bindable Commands))\
-can be used to find out the context and tag names used by completion
+ifnzman(noderef(Bindable Commands))
+can be used to find out the contexts and tag names used by completion
 functions. If it is invoked, it shows a list of context names and the
-tag names used in those contexts if completion were tried in the
+tag names used in those contexts if completion were tried at the
 current cursor position. This allows one to easily find out all the
 information needed to change the tt(_sort_tags) function when one
 wants to change the way matches are generated for that context.
@@ -506,14 +495,14 @@
 tested in the order in which they were given. But that isn't
 completely true. In fact, this function roughly sorts the patterns so
 that more specialized patterns are compared before more general
-patterns. Due to this, the last two examples could be defined before
+patterns. Due to this, the last two examples could be defined after
 the first one because both `tt(*:kill:*)' and `tt(*:kill*:jobs)' are
-considered to be more special then the pattern `tt(*)' from the first
-example. When decided how specific a pattern is, the function looks at 
+considered to be more specific then the pattern `tt(*)' from the first
+example. To decide how specific a pattern is, the function looks at 
 the number of colons (corresponding to the number of components) used
 in the pattern, and if these components are actual patterns (like the
 `tt(*)') or simple strings (like the `tt(jobs)' in the last
-example). Patterns with fewer patterns and fewer simple strings are
+example). Patterns with fewer colons and fewer simple strings are
 considered to be less specific.
 
 As for tags, completion functions can use any number of styles, so
@@ -597,7 +586,7 @@
 used for X font names
 )
 item(tt(functions))(
-names of functions (shell function or other kinds of functions for
+names of functions (shell functions or other kinds of functions for
 some commands)
 )
 item(tt(globbed-files))(
@@ -638,7 +627,7 @@
 for map names (e.g. YP maps)
 )
 item(tt(matches))(
-used to look up the tt(matches) style
+used to look up the tt(group) style
 )
 item(tt(messages))(
 used to look up the tt(format) style for messages
@@ -647,7 +636,7 @@
 for names of X modifiers
 )
 item(tt(modules))(
-for zsh modules
+for modules (e.g. tt(zsh) modules)
 )
 item(tt(named-directories))(
 for named directories (you wouldn't have guessed that, would you?)
@@ -662,13 +651,13 @@
 for command options
 )
 item(tt(packages))(
-for RPM packages
+for packages (e.g. tt(rpm) packages)
 )
 item(tt(parameters))(
 for names of parameters
 )
 item(tt(paths))(
-used to look up the values of the tt(expand) and tt(cursor) style
+used to look up the values of the tt(expand) and tt(cursor) styles
 )
 item(tt(pods))(
 for perl pods
@@ -689,7 +678,7 @@
 used to look up tt(cache-path) style
 )
 item(tt(sequences))(
-for MH sequences
+for sequences (e.g. tt(mh) sequences)
 )
 item(tt(sessions))(
 for sessions in the tt(zftp) function suite
@@ -702,7 +691,7 @@
 command)
 )
 item(tt(tags))(
-for RPM tags
+for tags (e.g. tt(rpm) tags)
 )
 item(tt(targets))(
 for makefile targets
@@ -779,13 +768,12 @@
 that call it when generating process identifiers as matches.
 )
 item(tt(auto-description))(
-If set, this string will be used as the description for options which
+If set, this style's value will be used as the description for options which
 are not described by the completion functions, but that have exactly
-one argument (note that this may not work for all commands).
-
-The sequence `tt(%d)' in the value will be replaced by the description
-for this argument. Depending on personal preferences, it may be useful
-to set this style to something like `tt(specify: %d)'.
+one argument. The sequence `tt(%d)' in the value will be replaced by
+the description for this argument. Depending on personal preferences,
+it may be useful to set this style to something like `tt(specify: %d)'. 
+Note that this may not work for some commands.
 )
 item(tt(cache-path))(
 The tt(_regex_arguments) utility function used by some completion
@@ -796,7 +784,7 @@
 )
 item(tt(completer))(
 The strings given as the value of this style give the names of the
-completer function to use. The available completer functions are
+completer functions to use. The available completer functions are
 described in
 ifzman(the section `Control Functions' below)\
 ifnzman(noderef(Control Functions))\
@@ -807,9 +795,9 @@
 
 If this is set to an non-empty string it should be an expression
 usable inside a `tt($((...)))' arithmetical expression. The completer
-function evaluates this expression and if the result is `tt(1)' no
+function evaluates this expression and if the result is `tt(1)', no
 expansions will be generated, but instead the completions will be
-generated as normal and all of them will be inserted in the command
+generated as normal and all of them will be inserted into the command
 line.
 )
 item(tt(condition))(
@@ -828,14 +816,14 @@
 )
 item(tt(cursor))(
 This is used together with the tt(paths) tag by the function
-generating filenames as matches to say that the cursor will be left
+generating filenames as matches to find out if the cursor will be left
 after the first ambiguous pathname component even when menucompletion
 is used.
 )
 item(tt(description))(
 This is used in several contexts to decide if only a simple or a
 verbose list of matches should be generated. For example some commands 
-show descriptions for option names if the style is true.
+show descriptions for option names if this style is true.
 )
 item(tt(disable-stat))(
 This is used with the tt(cvs) tag by the function completing for the
@@ -843,7 +831,7 @@
 generate only names of modified files in the appropriate places.
 )
 item(tt(expand))(
-Like tt(cursor) this style is used with the tt(paths) tag. If it is
+Like tt(cursor), this style is used with the tt(paths) tag. If it is
 set to `true', the partially typed path from the line will be
 expanded as far as possible even if trailing pathname components can
 not be completed.
@@ -855,16 +843,16 @@
 what these matches are. This string may also contain the sequences to
 specify output attributes, such as `tt(%b)' and `tt(%s)'.
 
-For the tt(messages) tag, this defines a string to display messages
-from the completion functions. Here, the `tt(%d)' is replaced with the 
-message given by the completion function.
+For the tt(messages) tag, this defines a string used by some
+completion functions to display messages. Here, the `tt(%d)' is
+replaced with the message given by the completion function.
 
 Finally, for the tt(warnings) tag, it is printed when no matches could 
 be generated at all. In this case the `tt(%d)' is replaced with the
 descriptions for the matches that were expected.
 )
 item(tt(glob))(
-Like tt(complete) this is used by the tt(_expand) completer.
+Like tt(complete), this is used by the tt(_expand) completer.
 
 The value is used like the one for tt(complete) and if it evaluates to 
 `tt(1)', globbing will be attempted on the words resulting from
@@ -923,8 +911,9 @@
 The tt(_history_complete_word) bindable command uses this style to
 decide if the available matches should be shown.
 
-In the tt(incremental-complete-word) widget, if it is `true', then the 
-matches are listed on every key press.
+When using the tt(incremental-complete-word) widget, this style says
+if the matches should be listed on every key press (if they fit on the 
+screen).
 )
 item(tt(list-arguments))(
 Like the tt(arguments) style, but used when calling the tt(ps) command 
@@ -1315,7 +1304,7 @@
 menucompletion allowing you to cycle through these strings.
 
 The exact behavior of this completer can be changed by using the
-style tt(accept), tt(original), tt(prompt), and tt(insert), see
+styles tt(accept), tt(original), tt(prompt), and tt(insert), see
 ifzman(the section `Completion System Configuration' above)\
 ifnzman(noderef(Completion System Configuration)).
 
@@ -1324,7 +1313,7 @@
 to generate matches, it will add another context name component
 containing the number of errors accepted in this attempt. So on the
 first try the context name starts with `tt(:approximate:1)', on the
-second try with `tt(:approximate:1)', and so on.
+second try with `tt(:approximate:2)', and so on.
 )
 item(tt(_correct))(
 Generate corrections (but not completions) for the current word; this is
@@ -1335,7 +1324,7 @@
 
 example(compstyle '*' completer _complete _correct _approximate
 compstyle ':correct' accept '2n!'
-compstyle ':approximate' accept 3n)
+compstyle ':approximate' accept '3n')
 
 correction will accept up to two errors. If a numeric argument is
 given, correction will not be performed, but correcting completion
@@ -1460,12 +1449,12 @@
 item(tt(_correct_word) (^Xc))(
 Performs correction of the current argument using the usual contextual
 completions as possible choices. This uses the top-level context name
-`tt(correct-word)' and then calls the tt(_correct) completer.
+`tt(:correct-word)' and then calls the tt(_correct) completer.
 )
 item(tt(_expand_word (^Xe)))(
 Performs expansion on the current word:  equivalent to the standard
 tt(expand-word) command, but using the tt(_expand) completer. Before
-calling it, the top-level context name is set to `tt(expand-word)'.
+calling it, the top-level context name is set to `tt(:expand-word)'.
 )
 item(tt(_history_complete_word) (\e/))(
 Complete words from the shell's command history.
@@ -1499,9 +1488,9 @@
 existing string instead of reading a new one.  To force a new string to be
 read, call tt(_read_comp) with a numeric argument.
 )
-item(tt(_complete_help))(
+item(tt(_complete_help (^Xh)))(
 This widget displays information about the context names and tags used 
-when completing for the place where the cursor is on the line.
+when completing at the current cursor position.
 )
 enditem()
 
@@ -1518,6 +1507,15 @@
 added.
 
 startitem()
+findex(_funcall)
+item(tt(_funcall) var(return) var(name) [ var(args) ... ])(
+If a function var(name) exists, it is called with the arguments
+var(args). Unless it is the empty string or a single hyphen,
+var(return) is taken as the name of a parameter and the return status
+from the called function is stored in it.
+The return value of tt(_funcall) itself is zero if the function
+var(name) exists and was called and non-zero otherwise.
+)
 item(tt(_compalso))(
 This function looks up the definitions for the context and command
 names given as arguments and calls the handler functions for them if
@@ -1575,7 +1573,7 @@
 completions can be generated automatically.
 
 This function also uses the tt(format) style for the tt(messages) tag in
-preference to tt(format) style for the tt(descriptions) tag. The
+preference to the tt(format) style for the tt(descriptions) tag. The
 latter is used only if the former is unset.
 )
 item(tt(_tags))(
@@ -1588,13 +1586,14 @@
 tag should be tried, the tt(_requested) function has to be called (see 
 below).
 
-The return value is zero if tags are requested and non-zero otherwise.
+The return value is zero if at least one of the tags is requested and
+non-zero otherwise. 
 
 This function also accepts the tt(-C) option followed by a name. This
 name is temporarily (i.e. not visible outside tt(_tags)) appended
 (with a colon before it) to the contents of the tt(curcontext)
 parameter. This allows to make tt(_tags) and tt(_sort_tags) use a
-more specific context name without havin to change and reset the
+more specific context name without having to change and reset the
 tt(curcontext) parameter (which would otherwise have the same effect).
 )
 item(tt(_requested))(
@@ -1604,7 +1603,6 @@
 done in a loop such as:
 
 example(_tags foo bar baz
-
 while _tags; do
   if _requested foo; then
     ...
@@ -1615,18 +1613,16 @@
 
 So, the first argument for tt(_requested) is used as the name of a tag 
 and if that tag is currently requested, the return value is zero (and
-non-zero otheriwse).
+non-zero otherwise).
 
-If more than one argument is given, tt(_requested) call the
+If more than one argument is given, tt(_requested) calls the
 tt(_description) function with all arguments except the first
 one. This is often useful to do both the testing of the tag and
-getiing the description for the matches one is about to add at
+getting the description for the matches one is about to add at
 once. E.g.:
 
 example(local expl ret=1
-
 _tags foo bar baz
-
 while _tags; do
   _requested foo expl 'description' &&
       compadd "$expl[@]" foobar foobaz && ret=0
@@ -1657,7 +1653,7 @@
 item(tt(_alternative))(
 This function is useful if you offer multiple tags and building the
 matches for them is easy enough. It basically implements a loop like
-the one described above for the tt(_tags) function.
+the one described above.
 
 The tags to use and what to do if the tags are requested are described 
 using the arguments which are of the form:
@@ -1677,7 +1673,7 @@
 to offer usernames and hostnames as possible matches (which are
 generated by the tt(_users) and tt(_hosts) functions respectively).
 
-Like tt(_tags) this function supports the tt(-C) option to give a
+Like tt(_tags) this function supports the tt(-C) option to give an
 additional context name component.
 )
 item(tt(_style))(
@@ -1687,20 +1683,22 @@
 current context name (preceded by a colon) and the patterns defined by 
 the user with the tt(compstyle) function will be compared to that
 combined name. If any of those pattern matches the name and the given
-style is defined for it and its boolean value is `true', tt(_style)
+style is defined for it and its boolean value is `true' (i.e. its
+value is one of `tt(true)', `tt(on)', `tt(yes)', and `tt(1)'), tt(_style)
 returns zero and non-zero otherwise. If you want to test the style not 
 only for a boolean value, you can give a third argument which is then
 used as a pattern and tt(_style) returns zero if the pattern matches
 the value defined for the style.
 
-If you want to retireve the value defined for the style, you can use
+If you want to retrieve the value defined for the style, you can use
 one of the options tt(-b) (to retrieve it as a boolean value, i.e. one 
 of tt(yes) or tt(no)), tt(-s) (to get it as a scalar, i.e. a string
 concatenated from the value strings defined by the user, separated by
 spaces), tt(-a) (to get it as an array), and tt(-h) (to get it as an
-associative array). In each of this cases the arguments after the
-option are the tag, the style-name and the name of the parameter into
-which the result will be stored.
+associative array; in this case the first, third, etc. strings from the 
+value are used as the keys and the others as their values). In each of
+these cases the arguments after the option are the tag, the style-name
+and the name of the parameter into which the result will be stored.
 
 For example, to test if the tt(description) style is set to `true' for 
 the current context and the tag tt(foo):
@@ -1719,19 +1717,6 @@
 definition for the style was found and non-zero if no definition was
 found.
 )
-item(tt(_display))(
-This function generates a display list usable for the `tt(-d)' option
-of tt(compadd). For this it takes its arguments except the first one
-as possible matches with descriptions. The strings should contain the
-match, optionally followed by a colon and the description for this
-match. From this tt(_display) builds an array with elements containing 
-the matches and their descriptions, where the descriptions are aligned.
-After that, the first argument is taken as a parameter name and the
-array built is stored in it.
-
-The return value of tt(_display) is zero if there was at least one
-match with a description non-zero otherwise.
-)
 item(tt(_describe))(
 This function can be used to add options or values with descriptions
 as matches. The first argument is taken as a string to display above
@@ -1886,7 +1871,7 @@
 `tt(*::)var(message)tt(:)var(action)') the tt(words) special array and 
 the tt(CURRENT) special parameter will be restricted to only the
 normal arguments when the var(action) is executed or evaluated. With
-three colons before the var(message) they will be restructed to only
+three colons before the var(message) they will be restricted to only
 the normal arguments covered by this description.
 )
 item(var(opt-spec)[var(description) ...])(
@@ -1942,7 +1927,7 @@
 
 Finally, the var(opt-spec) may contain a explanation string. This is
 given in brackets at the end, as in `tt(-q[query operation])'. The
-style tt(description) for the tt(options) tag is used to decide if these
+tt(description) style for the tt(options) tag is used to decide if these
 explanation strings should be printed when options are listed. If no
 explanation string is given but the tt(auto-describe) style is
 set and only one argument is described for this var(opt-spec), the
@@ -1959,7 +1944,7 @@
 doubled parentheses, as in `tt(:foo:((a\:bar b\:baz)))' should contain 
 strings consisting of the string to complete followed by a colon
 (which needs to be preceded by a backslash) and a description. The
-matches will be listed together with their descriptions the
+matches will be listed together with their descriptions if the
 tt(description) style for the tt(values) tag is set.
 
 An var(action) of the form `tt(->)var(string)' is used by functions
@@ -1985,7 +1970,7 @@
 var(action) does not begin with an opening parentheses or brace, it
 will be split into separate words and executed. If the var(action)
 starts with a space, this list of words will be invoked unchanged,
-otherwise it will be invoked with some extra string placed after the
+otherwise it will be invoked with some extra strings placed after the
 first word which can be given as arguments to the tt(compadd) builtin
 command and which make sure that the var(message) given
 in the description will be shown above the matches. These arguments
@@ -2015,19 +2000,14 @@
 a string of the form `var(-opt)tt(-)var(n)' for the var(n)'th argument 
 of the option var(-opt), or a string of the form `tt(argument-)var(n)' 
 for the var(n)'th argument (for rest arguments the var(n) is the
-string `tt(rest)').
-
-Also, during the evaluation of the var(action), the context name will
-be changed by adding another component describing the option or
-argument for which the action is executed. For arguments of options,
-the name is build from the name of the option followed by a hyphen and 
-the number of the argument (starting with `tt(1)'). For arguments the
-name added is the string tt(argument-) followed by the number of the
-argument or the string tt(rest) if this is for a `tt(*:...)'
-definition. For example, when completing the argument of the tt(-o)
+string `tt(rest)'). For example, when completing the argument of the tt(-o)
 option, the name is `tt(-o-1)' and for the second normal (non-option-)
 argument it is `tt(argument-2)'.
 
+Also, during the evaluation of the var(action), the context name in
+the tt(curcontext) parameter will be changed by appending the same
+string that is stored in the tt(context) parameter.
+
 Normally the option names are taken as multi-character names and a
 word from the line is considered to contain only one option (or
 none). By giving the tt(-s) option to this function (before the first
@@ -2042,7 +2022,7 @@
 taken as the name of an array and its elements will be given to
 functions called to generate matches when executing the
 var(actions). For example, this allows one to give options for the
-tt(compadd) builtin that should be used.
+tt(compadd) builtin that should be used for all var(action)s.
 
 Also, the tt(-M) option followed by a string may be given before the
 first description. The string will be used as the match specification
@@ -2069,7 +2049,8 @@
 to make sure that this feature is not used for a command that does not
 support this option.
 
-For options that get an argument after a `tt(=)', the function also tries
+For such automatically found options that get an argument after a
+`tt(=)', the function also tries
 to automatically find out what should be completed as the argument.
 The possible completions for option-arguments can be described with
 the arguments after the `tt(-)tt(-)' (which are not used as described
@@ -2112,18 +2093,19 @@
 completion of the second form, one would use `tt(-s "LPAR()#-)tt(-enable-
 -)tt(-disable-RPAR()")'.
 
-Finally, this function uses the styles tt(prefix-hidden) and
-tt(prefix-needed).
+Finally, this function uses the styles tt(description),
+tt(prefix-hidden) and tt(prefix-needed) with the tt(options) tag when
+generating option names as matches.
 
 Example:
 
-example(_arguments '-l+:left border:' \
-           '-format:paper size:(letter A4)' \
-	   '*-copy:output file:_files::resolution:(300 600)' \
-	   ':postscript file:_files -g *.(ps|eps)' \
+example(_arguments '-l+:left border:' \ 
+           '-format:paper size:(letter A4)' \ 
+	   '*-copy:output file:_files::resolution:(300 600)' \ 
+	   ':postscript file:_files -g *.(ps|eps)' \ 
 	   '*:page number:')
 
-This describes three options `tt(-l)', `tt(-format)', and
+This describes three options: `tt(-l)', `tt(-format)', and
 `tt(-copy)'. The first one gets one argument described as `var(left
 border)' for which no completion will be offered because of the empty
 action. The argument may come directly after the `tt(-l)' or it may be 
@@ -2154,7 +2136,7 @@
 
 Otherwise, if the first argument (or the first argument after the
 `tt(-O) var(name)' option if that is used) is the option `tt(-s)', the
-second argument is used as the character that separates multiple values.
+next argument is used as the character that separates multiple values.
 
 The first argument (after the options and separator character if they
 are given) is used as a string to print as a description before
@@ -2168,9 +2150,9 @@
 
 Example:
 
-example(_values -s , '...' \
+example(_values -s , 'description' \ 
         '*foo[bar]' \
-        '(two)*one[number]:first count:' \
+        '(two)*one[number]:first count:' \ 
         'two[another number]::second count:(1 2 3)')
 
 This describes three possible values: `tt(foo)', `tt(one)', and
@@ -2179,7 +2161,7 @@
 `tt(number)', may appear more than once, and gets one mandatory
 argument described as `tt(first count)' for which no action is
 specified so that it will not be completed automatically. The
-`tt((one))' at the beginning says that if the value `tt(one)' is on
+`tt((two))' at the beginning says that if the value `tt(one)' is on
 the line, the value `tt(two)' will not be  considered to be a possible
 completion any more. Finally, the last value (`tt(two)') is described
 as `tt(another number)' and gets an optional argument decribed as
@@ -2196,7 +2178,8 @@
 arguments) should be printed, the style tt(description) for the
 tt(values) tag is used.
 
-One last difference is that this function uses the associative array
+One last difference to tt(_arguments) is that this function uses the
+associative array
 tt(val_args) to report values and their arguments (but otherwise this
 is the same as the tt(opt_args) association used by
 tt(_arguments)). This also means that the function calling tt(_values) 
diff -u -r oldcompletion/Core/_funcall Completion/Core/_funcall
--- oldcompletion/Core/_funcall	Thu Nov 18 09:41:06 1999
+++ Completion/Core/_funcall	Thu Nov 18 09:02:31 1999
@@ -0,0 +1,32 @@
+#autoload
+
+# Utility function to call a function if it exists.
+#
+# Usage: _funcall <return> <name> [ <args> ... ]
+#
+# If a function named <name> is defined (or defined to be autoloaded),
+# it is called. If <return> is given not the string `-' or empty, it is
+# taken as the name of a parameter and the return status of the function
+# called is stored in this parameter. All other arguments are given
+# to the function called.
+# The return value of this function is zero if the function was
+# called and non-zero otherwise.
+
+local _name _ret
+
+[[ "$1" != (|-) ]] && _name="$1"
+
+shift
+
+if (( $+functions[$1] )); then
+  "$@"
+  _ret="$?"
+
+  [[ -n "$_name" ]] && eval "${_name}=${_ret}"
+
+  compstate[restore]=''
+
+  return 0
+fi
+
+return 1
diff -u -r oldcompletion/Core/compinit Completion/Core/compinit
--- oldcompletion/Core/compinit	Thu Nov 18 08:51:31 1999
+++ Completion/Core/compinit	Thu Nov 18 09:00:56 1999
@@ -497,35 +497,6 @@
 compstyle ':correct' prompt        'correct to:'
 compstyle '*'        completer     '_complete'
 
-# Utility function to call a function if it exists.
-#
-# Usage: funcall <return> <name> [ <args> ... ]
-#
-# If a function named <name> is defined (or defined to be autoloaded),
-# it is called. If <return> is given not the string `-' or empty, it is
-# taken as the name of a parameter and the return status of the function
-# called is stored in this parameter. All other arguments are given
-# to the function called.
-# The return value of this function is zero if the function was
-# called and non-zero otherwise.
-
-funcall() {
-  local _name _ret
-
-  [[ "$1" != (|-) ]] && _name="$1"
-
-  shift
-
-  if (( $+functions[$1] )); then
-    "$@"
-    _ret="$?"
-    [[ -n "$_name" ]] && eval "${_name}=${_ret}"
-    compstate[restore]=''
-    return 0
-  fi
-  return 1
-}
-
 # Now we automatically make the definition files autoloaded.
 
 typeset -U _i_files
diff -u -r oldcompletion/Linux/_rpm Completion/Linux/_rpm
--- oldcompletion/Linux/_rpm	Thu Nov 18 08:51:33 1999
+++ Completion/Linux/_rpm	Thu Nov 18 09:03:03 1999
@@ -79,7 +79,7 @@
 
   # First try to call a user-defined function.
 
-  funcall ret _rpm_$state && return ret
+  _funcall ret _rpm_$state && return ret
 
   # Copy the state and reset `state', to simplify the test above.
 
diff -u -r oldcompletion/User/_nslookup Completion/User/_nslookup
--- oldcompletion/User/_nslookup	Thu Nov 18 08:51:36 1999
+++ Completion/User/_nslookup	Thu Nov 18 09:03:19 1999
@@ -50,7 +50,7 @@
 if [[ -n "$compcontext" ]]; then
   if [[ CURRENT -eq 1 ]]; then
 
-    funcall ret _nslookup_command && return ret
+    _funcall ret _nslookup_command && return ret
 
     _alternative \
         'commands:command:compadd server lserver root finger ls view help set' \
@@ -58,7 +58,7 @@
     return ret
   elif [[ "$compstate[context]" = redirect ]]; then
 
-    funcall ret _nslookup_redirect && return ret
+    _funcall ret _nslookup_redirect && return ret
 
     _tags -C redirection files || return 1
 
@@ -79,9 +79,9 @@
   fi
 
   if [[ "$words[1]" = [a-z]## ]]; then
-    funcall ret _nslookup_$words[1] && return ret
+    _funcall ret _nslookup_$words[1] && return ret
   else
-    funcall ret _nslookup_host && return ret
+    _funcall ret _nslookup_host && return ret
   fi
 
   case "$words[1]" in

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


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

* PATCH: cleanup
@ 1999-11-18  9:52 Sven Wischnowsky
  1999-11-18 12:09 ` Adam Spiers
  0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 1999-11-18  9:52 UTC (permalink / raw)
  To: zsh-workers


This contains mostly cleanups for the manual stuff.

But it also contains some hunks to put `funcall' in its own file (and
naming that `_funcall', of course).


And reading the whole of compsys.yo again, it made ne notice that we
really need another name instead of `tags' because that's already used
for the `#compdef' and `#autoload' things.


And a question: as I already said, I'd like to change the name of the
`description' style to `verbose' But there are other turned-into-styles
config keys which could do with a bit of cleanup. For example we could 
use the `accept' style use seperate string instead of that ugly `2n!'
stuff. And we could change styles like `menu' to use separate words,
too, instead of the `*whatever*' test we have now, or, probably
better, we could try to split some of the styles into multiple styles
with better names. And we could turn styles like `insert' into boolean 
types. Finally we could think about styles that are used like
`last-prompt' but turn on menu-completion, -selection, and the
listing-options.

The question is: is now the right time for such changes or should we
wait until we all have gotten used to the styles stuff?

Bye
 Sven

diff -u oldsrc/Zle/compcore.c Src/Zle/compcore.c
--- oldsrc/Zle/compcore.c	Wed Nov  3 12:53:50 1999
+++ Src/Zle/compcore.c	Thu Nov  4 11:23:30 1999
@@ -428,7 +428,7 @@
     /* If we are doing a menu-completion... */
 
     if (menucmp && *lst != COMP_LIST_EXPAND && 
-	(!compwidget || compwidget == lastcompwidget)) {
+	(menucmp != 1 || !compwidget || compwidget == lastcompwidget)) {
 	do_menucmp(*lst);
 	return 1;
     }
diff -u oldsrc/Zle/complist.c Src/Zle/complist.c
--- oldsrc/Zle/complist.c	Wed Nov  3 12:53:50 1999
+++ Src/Zle/complist.c	Thu Nov  4 11:30:04 1999
@@ -545,7 +545,7 @@
     Cmgroup *pg;
     Thingy cmd;
     Menustack u = NULL;
-    int i = 0, acc = 0, wishcol = 0, setwish = 0, oe = onlyexpl;
+    int i = 0, acc = 0, wishcol = 0, setwish = 0, oe = onlyexpl, wasnext = 0;
     char *s;
 
     HEAPALLOC {
@@ -591,7 +591,7 @@
 		while (mcol < mcols - 1 && p[1] == minfo.cur)
 		    mcol++, p++, pg++;
 	    }
-	    setwish = 0;
+	    setwish = wasnext = 0;
 
 	getk:
 
@@ -634,7 +634,7 @@
 		}
 		clearlist = listshown = 1;
 		mselect = (*(minfo.cur))->gnum;
-		setwish = 1;
+		setwish = wasnext = 1;
 		continue;
 	    } else if (cmd == Th(z_acceptandhold) ||
 		       cmd == Th(z_acceptandmenucomplete)) {
@@ -858,6 +858,11 @@
 	if (acc) {
 	    menucmp = lastambig = hasoldlist = 0;
 	    do_single(*(minfo.cur));
+	}
+	if (wasnext) {
+	    menucmp = 2;
+	    showinglist = -2;
+	    minfo.asked = 0;
 	}
 	if (!noselect) {
 	    showinglist = -2;
diff -u oldsrc/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- oldsrc/Zle/zle_tricky.c	Wed Nov  3 12:53:51 1999
+++ Src/Zle/zle_tricky.c	Thu Nov  4 11:24:49 1999
@@ -77,7 +77,8 @@
 /**/
 int usemenu, useglob;
 
-/* != 0 if we are in the middle of a menu completion. */
+/* != 0 if we are in the middle of a menu completion. May be == 2 to force *
+ * menu completion even if using different widgets.                        */
 
 /**/
 int menucmp;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


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

end of thread, other threads:[~1999-12-15 20:31 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-18 10:02 PATCH: cleanup Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
1999-12-15 15:26 Sven Wischnowsky
1999-12-15 20:31 ` Peter Stephenson
1999-12-09 10:35 Sven Wischnowsky
1999-11-18 14:49 Sven Wischnowsky
1999-11-18 10:03 Sven Wischnowsky
1999-11-18  9:52 Sven Wischnowsky
1999-11-18 12:09 ` Adam Spiers

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).