Re: 3.1.6-dev-18

Re: 3.1.6-dev-18

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
>
> It took me a while to work out what you were saying, but I think it's that
> while `blah1 blah2' used to be tried one after another when they were
> elements of $compmatchers, they get tried all at once if they are elements
> of the matcher style in the form I gave it.  If that's correct, I doubt if
> that's a major issue for most users --- I suspect that most people who used
> more than one element of $compmatchers just had different things in them,
> as I did.

Hopefully, giving the same string more than once wouldn't make sense.

> Still, how much do you gain by being able to put them in matcher-1 and
> matcher-2?  Is that more powerful than just using array elements of the
> style in order, rather than simply more cumbersome?  The only examples I
> can think of where you gain something are where _matcher is followed the
> second time by _prefix instead of _complete (or vice versa), or where some
> other element of the context is different between the matcher-1 and
> matcher-2 cases.  These seem to me to be to abstruse to be useful.  But I
> may well have missed something.

I can only repeat... I would have no problems with turning the matcher 
style as used by _matcher (or even renaming it for clarity) into one
that is used as an array. The first _matcher would then use the first
string in the value, the second one the second string and so on. I
just thought -- and I may very well be wrong here -- that it would
make users more aware of what they are doing if we use this more
explicit setting we have now. I.e., even with the suggested
array-interpretation of the matcher style one would have to add a new
call to _matcher in the completer list when adding a new string to the 
matcher style.

Hm. If anyone now says: change it, I will (renaming the style so that
it doesn't look like the matcher style used for tags -- which is
looked up as a string).

Bye
 Sven


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

RE: 3.1.6-dev-18

[Andrej Borsenkow]

>
> > Still, how much do you gain by being able to put them in matcher-1 and
> > matcher-2?  Is that more powerful than just using array elements of the
> > style in order, rather than simply more cumbersome?  The only examples I
> > can think of where you gain something are where _matcher is followed the
> > second time by _prefix instead of _complete (or vice versa), or
> where some
> > other element of the context is different between the matcher-1 and
> > matcher-2 cases.  These seem to me to be to abstruse to be
> useful.  But I
> > may well have missed something.
>
> I can only repeat... I would have no problems with turning the matcher
> style as used by _matcher (or even renaming it for clarity) into one
> that is used as an array. The first _matcher would then use the first
> string in the value, the second one the second string and so on. I
> just thought -- and I may very well be wrong here -- that it would
> make users more aware of what they are doing if we use this more
> explicit setting we have now. I.e., even with the suggested
> array-interpretation of the matcher style one would have to add a new
> call to _matcher in the completer list when adding a new string to the
> matcher style.
>

Please, no. It will be worse than it is now.

When I spoke about array, I meant absolutely different thing. Remove
_matcher completer alltogether. Setup a style with match specs, that will be
tried in order. In other words

zstyle :completion::complete::::: match_specs "" spec1 spec2 ...

with semantics

_complete should try this list in order until it gets matches.

I agree, that your way provides more fine grained control ... the question
is, how complex completion system is going to be? Do you think, that an
everage user would ever need such a complexity?

And what occured to me ... why _oldlist, _prefix etc are completers at all?
They look much more like actually a styles to me! They do not generate any
matches - rather, they say completion system _how_ to generate matches. So,
somewhat revolutionary ;-) idea:

leave only _complete
use styles to describe, just how _complete should do completion. Something
like

:completion::complete:::::pass-1 flags normal
:completion::complete:::::pass-2 flags prefix
:completion::complete:::::pass-3 flags match keeplist
:completion::complete:::::pass-4 flags approximate prefix

and additional

:completion::complete:::::pass-1 match_specs "" spec1 spec2

with semantics

first try normal with completion with empty, spec1, spec2. If nothin works,
try prefix; if this fails, try match keeping old list; and if this fails,
try approximate.

/andrej

Re: 3.1.6-dev-18

[Peter Stephenson]

Sven Wischnowsky wrote:
> I can only repeat... I would have no problems with turning the matcher 
> style as used by _matcher (or even renaming it for clarity) into one
> that is used as an array. The first _matcher would then use the first
> string in the value, the second one the second string and so on. I
> just thought -- and I may very well be wrong here -- that it would
> make users more aware of what they are doing if we use this more
> explicit setting we have now. I.e., even with the suggested
> array-interpretation of the matcher style one would have to add a new
> call to _matcher in the completer list when adding a new string to the 
> matcher style.

Given the last sentence, your way of doing things does make more sense.
But I appreciate Andrej's point that the _matcher completer ideally
shouldn't be necessary at all, given that there's a style controlling it.
If there is some magic which could go in, say, _main_complete to handle
this, it would be nice.  For example, start with matcher-1, try with that;
then retrieve matcher-N, continuing until either you get the same string as
before (assumption: there was a * in the matcher column), or you get
nothing (assumption: the style's not set at all); plus do some optimisation
based on which completers don't use matching at all, to avoid calling
completers unnecessarily.

On the other discussion, I'm certainly not hung up on providing
alternatives to the string context, which I think is pretty usable when you
get your mind round it.  It's more a question of what the punters think
than what I think.

By the way, should there be a style that says that old-style completions
are to be used?  It would avoid the necessity of customizing _default.

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

Re: 3.1.6-dev-18

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > Err, hadn't thought about putting that into _main_complete (where we
> > can optimise).
> > 
> > One last question: wouldn't it then be better to just have a
> > matcher-list style, taken as an array, containing the match specs to
> > try one after another?
> 
> Under those circumstances, probably yes; there's no obvious advantage in
> pretending you have multiple matching functions if you don't.

Ok, here is the matcher-list style. Ultra-short description: it is
enough to set:

  zstyle ':completion:*' matcher-list '' 'm:{a-z}={A-Z}'

(or whatever you prefer). No fiddling with the completer style and so
on... unless you want it and you may want it because I couldn't hold
myself back to make this more powerful, see the docs for further
enlightenment. I hope to have made this easy for simple cases and
still as powerful as the _matcher completer. (But note that due to the 
first problem mentioned in 9771 the lookup-name for the first
completer is wrong.)

And the _matcher file can, of course, be removed now.


For writers of completers (real completers, not simple completion
functions): we should now test again if we are using the first matcher 
to avoid executing completers that don't use match specs more than
once. See _approximate, _expand, etc. for an example. I've made the
whole list of matchers, the current matcher and the index into the
array of matchers available via the parameters _matchers, _matcher,
and _matcher_num (the completers, btw. are available as $_completers,
$_completer, and $_completer_num).

Bye
 Sven

diff -ru ../z.old/Completion/Core/_approximate Completion/Core/_approximate
--- ../z.old/Completion/Core/_approximate	Thu Feb 17 10:23:18 2000
+++ Completion/Core/_approximate	Thu Feb 17 10:49:37 2000
@@ -5,12 +5,13 @@
 # shown in a list and one can cycle through them as in a menucompletion
 # or get the corrected prefix.
 
-local _comp_correct _correct_expl comax cfgacc
-local curcontext="${curcontext}" oldcontext opm="$compstate[pattern_match]"
+# We don't try correction if the string is too short or we have tried it
+# already.
 
-# We don't try correction if the string is too short.
+[[ _matcher_num -gt 1 || "${#:-$PREFIX$SUFFIX}" -le 1 ]] && return 1
 
-[[ "${#:-$PREFIX$SUFFIX}" -le 1 ]] && return 1
+local _comp_correct _correct_expl comax cfgacc
+local curcontext="${curcontext}" oldcontext opm="$compstate[pattern_match]"
 
 [[ "$curcontext" != [^:]#:correct:* ]] &&
     curcontext="${curcontext/:[^:]#:/:approximate:}"
diff -ru ../z.old/Completion/Core/_description Completion/Core/_description
--- ../z.old/Completion/Core/_description	Thu Feb 17 10:23:18 2000
+++ Completion/Core/_description	Thu Feb 17 10:54:42 2000
@@ -27,7 +27,7 @@
     [[ -z "$gname" ]] && gname="$1"
 zstyle -s ":completion:${curcontext}:$1" matcher match &&
     opts=($opts -M "${(q)match}")
-[[ -n "$_comp_matcher" ]] && opts=($opts -M "${(q)_comp_matcher}")
+[[ -n "$_matcher" ]] && opts=($opts -M "${(q)_matcher}")
 
 if zstyle -a ":completion:${curcontext}:$1" ignored-patterns _comp_ignore; then
   opts=( $opts -F _comp_ignore)
diff -ru ../z.old/Completion/Core/_expand Completion/Core/_expand
--- ../z.old/Completion/Core/_expand	Thu Feb 17 10:23:19 2000
+++ Completion/Core/_expand	Thu Feb 17 10:50:08 2000
@@ -7,6 +7,8 @@
 # the expansions done produce no result or do not change the original
 # word from the line.
 
+[[ _matcher_num -gt 1 ]] && return 1
+
 local exp word="$PREFIX$SUFFIX" sort expr expl subd suf=" "
 local curcontext="${curcontext/:[^:]#:/:expand:}"
 
diff -ru ../z.old/Completion/Core/_list Completion/Core/_list
--- ../z.old/Completion/Core/_list	Thu Feb 17 10:23:19 2000
+++ Completion/Core/_list	Thu Feb 17 10:50:22 2000
@@ -4,6 +4,8 @@
 # insert possible completions only after the list has been shown at
 # least once.
 
+[[ _matcher_num -gt 1 ]] && return 1
+
 local pre suf expr curcontext="${curcontext/:[^:]#:/:list:}"
 
 # Get the strings to compare.
diff -ru ../z.old/Completion/Core/_main_complete Completion/Core/_main_complete
--- ../z.old/Completion/Core/_main_complete	Thu Feb 17 10:23:19 2000
+++ Completion/Core/_main_complete	Thu Feb 17 11:31:12 2000
@@ -20,7 +20,8 @@
 unsetopt markdirs globsubst shwordsplit nounset ksharrays
 
 local comp post ret=1 _compskip format _comp_ignore \
-      _completers _completers_left _comp_matcher \
+      _completers _completer _completer_num \
+      _matchers _matcher _matcher_num \
       context state line opt_args val_args curcontext="$curcontext" \
       _last_nmatches=-1 _last_menu_style _def_menu_style _menu_style sel \
       _saved_exact="${compstate[exact]}" \
@@ -62,14 +63,22 @@
 # And now just call the completer functions defined.
 
 _completers=( "$@" )
-_completers_left=( "$@" )
+_completer_num=1
 
-for comp; do
-  if "$comp"; then
-    ret=0
-    break;
-  fi
-  shift 1 _completers_left
+for _completer; do
+  _matcher="${_completer[2,-1]}-${(M)#_completers[1,_completer_num]:#$_completer}"
+  zstyle -a ":completion:${curcontext/::/:${_matcher}:}:" matcher-list _matchers ||
+      _matchers=( '' )
+
+  _matcher_num=1
+  for _matcher in "$_matchers[@]"; do
+    if "$_completer"; then
+      ret=0
+      break 2
+    fi
+    (( _matcher_num++ ))
+  done
+  (( _completer_num++ ))
 done
 
 if [[ $compstate[nmatches] -gt 1 ]]; then
diff -ru ../z.old/Completion/Core/_match Completion/Core/_match
--- ../z.old/Completion/Core/_match	Thu Feb 17 10:23:19 2000
+++ Completion/Core/_match	Thu Feb 17 10:50:35 2000
@@ -9,6 +9,8 @@
 # expand-or-complete function because otherwise the pattern will
 # be expanded using globbing.
 
+[[ _matcher_num -gt 1 ]] && return 1
+
 local tmp opm="$compstate[pattern_match]" ret=0 orig ins
 local curcontext="${curcontext/:[^:]#:/:match:}"
 
diff -ru ../z.old/Completion/Core/_menu Completion/Core/_menu
--- ../z.old/Completion/Core/_menu	Thu Feb 17 10:23:19 2000
+++ Completion/Core/_menu	Thu Feb 17 10:50:43 2000
@@ -1,5 +1,7 @@
 #autoload
 
+[[ _matcher_num -gt 1 ]] && return 1
+
 local curcontext="${curcontext/:[^:]#:/:menu:}"
 
 # This completer is an example showing how menucompletion can be
diff -ru ../z.old/Completion/Core/_oldlist Completion/Core/_oldlist
--- ../z.old/Completion/Core/_oldlist	Thu Feb 17 10:23:19 2000
+++ Completion/Core/_oldlist	Thu Feb 17 10:50:51 2000
@@ -1,5 +1,7 @@
 #autoload
 
+[[ _matcher_num -gt 1 ]] && return 1
+
 local curcontext="${curcontext/:[^:]#:/:oldlist:}" list
 
 zstyle -s ":completion:${curcontext}:" list list
diff -ru ../z.old/Completion/Core/_prefix Completion/Core/_prefix
--- ../z.old/Completion/Core/_prefix	Thu Feb 17 10:23:21 2000
+++ Completion/Core/_prefix	Thu Feb 17 10:44:02 2000
@@ -4,10 +4,10 @@
 
 [[ -n "$SUFFIX" ]] || return 1
 
-local curcontext="${curcontext/:[^:]#:/:prefix-${(M)#${(@)_completers[1,-$#_completers_left]}:#_prefix}:}" comp i
+local curcontext="${curcontext/:[^:]#:/:prefix-${(M)#_completers[1,_completer_num]:#_prefix}:}" comp i
 
 zstyle -a ":completion:${curcontext}:" completer comp ||
-  comp=( "${(@)_completers[1,-${#_completers_left}-1][(R)_prefix,-1]}" )
+  comp=( "${(@)_completers[1,_completer_num][(R)_prefix,-1]}" )
 
 if zstyle -t ":completion:${curcontext}:" add-space; then
   ISUFFIX=" $SUFFIX"
@@ -16,14 +16,8 @@
 fi
 SUFFIX=''
 
-local _completers _completer_left
-
-_completers=( "$comp[@]" )
-_completers_left=( "$comp[@]" )
-
 for i in "$comp[@]"; do
   [[ "$i" != _prefix ]] && "$i" && return 0
-  shift 1 _completers_left
 done
 
 return 1
diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Thu Feb 17 10:23:00 2000
+++ Doc/Zsh/compsys.yo	Thu Feb 17 11:47:02 2000
@@ -1089,11 +1089,50 @@
 ifzman(the section `Matching Control' in zmanref(zshcompwid))\
 ifnzman(noderef(Matching Control))\
 .
-
-This style is also used by the tt(_matcher) completer, see
-ifzman(the section `Control Functions' below)\
-ifnzman(noderef(Control Functions)) 
-for more information.
+)
+item(tt(matcher-list))(
+This style is used by the main completion function to retrieve match
+specifications that are to be used everywhere. Its value should be a
+list of such specifications. The completion system will try them one
+after another for each completer selected. For example, to first try
+simple completion and, if that generates no matches, case-insensitive
+completion one would do:
+
+example(zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}')
+
+But the style allows even finer control: the style is looked up for
+every completer tried with the name of the completer (without the
+leading underscore) in the context name. For example, if one uses the
+completers tt(_complete) and tt(_prefix) and wants to try
+case-insensitive completion only when using the tt(_complete)
+completer, one would do:
+
+example(zstyle ':completion:*' completer _complete _prefix
+zstyle ':completion:*:complete*:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}')
+
+Note that there is no colon directly after the `tt(complete)'. That's
+because the completion system really uses the name of the completer
+followed by a minus sign and a number in the var(completer) field of
+the context name. This is useful if, for example, one wants to try
+normal completion without a match specification and with
+case-insensitive matching first, correction if that doesn't generate
+any matches and partial-word completion if that doesn't yield any
+matches either. In such a case one can give the tt(_complete)
+completer more than once in the tt(completer) style and give different
+match specification to them, as in:
+
+example(zstyle ':completion:*' completer _complete _correct _complete
+zstyle ':completion:*:complete-1:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}'
+zstyle ':completion:*:complete-2:*' matcher-list \
+    'm:{a-zA-Z}={A-Za-z} r:|[-_./]=* r:|=*')
+
+Note that in any case an unset style makes the completion code use no
+global match specification. Also, some completers (like tt(_correct)
+and tt(_approximate)) do not use the match specifications. But even if 
+such completers are used one can use the simple form to set this style 
+(as in the first example above) because such completers will make sure 
+that they are executed only once even if multiple match specifications 
+have been given.
 )
 item(tt(max-errors))(
 This is used by the tt(_approximate) and tt(_correct) completer functions
@@ -1608,42 +1647,6 @@
 
 Note that the matcher specifications defined globally or used by the
 completion functions will not be used.
-)
-findex(_matcher)
-item(tt(_matcher))(
-This completer allows to define a match specification (see
-ifzman(the section `Matching Control' in zmanref(zshcompwid))\
-ifnzman(noderef(Matching Control))\
-) that is to be used by all following completers. This is comparable
-to the global match specifications that can be defined for the
-tt(compctl) builtin, but gives much better control. The match
-specification to use is looked up using the tt(matcher) style. For
-this, the completer field of the context name will contain the string
-`tt(matcher-)var(n)', where `var(n)' is the number of the call to
-tt(_matcher). For example:
-
-example(zstyle ':completion:::::' completer _matcher _complete _matcher _complete
-zstyle ':completion:*:matcher-1:::' matcher 'm:{a-z-}={A-Z_}'
-zstyle ':completion:*:matcher-2:::' matcher 'm:{a-z-}={A-Z_}' 'r:|[-_./]=* r:|=*')
-
-Since tt(_matcher) is called as the first completer, the tt(_complete) 
-completer called after it will first use the match specification
-`tt(m:{a-z-}={A-Z_})'. If that doesn't generate any matches, the next
-call to tt(_matcher) will make the second call to tt(_complete) use
-the specification `tt(r:|[-_./]=* r:|=*)' in addition to the one
-already used by the first attempt (but note that the specification has 
-to be given again).
-
-If the tt(matcher) style is not set for one of the invocations of
-tt(_matcher), this has the same effect as setting it to the empty
-string: it makes the following completion function not use any match
-specifications besides those used by the functions themselves.
-
-Note that currently only the tt(_complete) completer and the
-tt(_prefix) completer (if it has its own tt(completer) style
-containing tt(_complete)) use the match specifications, so one doesn't 
-need to repeat all completers one wants to use after each call to
-tt(_matcher) in the completer list.
 )
 findex(_expand)
 item(tt(_expand))(

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

Re: 3.1.6-dev-18

[Peter Stephenson]

Sven Wischnowsky wrote:
> Err, hadn't thought about putting that into _main_complete (where we
> can optimise).
> 
> One last question: wouldn't it then be better to just have a
> matcher-list style, taken as an array, containing the match specs to
> try one after another?

Under those circumstances, probably yes; there's no obvious advantage in
pretending you have multiple matching functions if you don't.

>> Firstly, I did
>> 
>> % less ~/.<TAB>
>> 
>> and got a list of files not beginning with a dot amongst those which did.
>
> I don't get that. Let me guess: somehow you ended up with your
> 'r:|[.,_-]=* r:|=*' match spec being tried immediatly or used always
> (as would happen with your setup from 9700, because the matcher style
> is tested for every tag).

That's probably right.  I imagine what confused me is exactly the change we
are discussing above, i.e. I only added one _matcher, which contains the
spec in question which is therefore applied immediately, whereas before it
happened later because it was in the second element of $compmatchers.
So I can easily fix it using styles.

> But maybe we should make _multi_parts use the `expand=suffix'
> style/value to decide if the whole matches should be used at all. The
> same way _path_files does that. I would prefer to make it use an empty 
> tag then (because _multi_parts doesn't always complete paths and the
> style is tested for the paths tag in _path_files). Because of that I
> thought, I should ask first. Or maybe making it use the paths tag in
> _path_files and no tag in _multi_parts is ok? (I find that a bit
> confusing).

Empty tags are certainly easier than they were before, so I would be in
favour of changing not to use tags unless they actually discriminate
between different cases ---- depending really on logic, i.e. we have less
need of inventing otherwise unused tags.

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

Re: 3.1.6-dev-18

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > I can only repeat... I would have no problems with turning the matcher 
> > style as used by _matcher (or even renaming it for clarity) into one
> > that is used as an array. The first _matcher would then use the first
> > string in the value, the second one the second string and so on. I
> > just thought -- and I may very well be wrong here -- that it would
> > make users more aware of what they are doing if we use this more
> > explicit setting we have now. I.e., even with the suggested
> > array-interpretation of the matcher style one would have to add a new
> > call to _matcher in the completer list when adding a new string to the 
> > matcher style.
> 
> Given the last sentence, your way of doing things does make more sense.
> But I appreciate Andrej's point that the _matcher completer ideally
> shouldn't be necessary at all, given that there's a style controlling it.
> If there is some magic which could go in, say, _main_complete to handle
> this, it would be nice.  For example, start with matcher-1, try with that;
> then retrieve matcher-N, continuing until either you get the same string as
> before (assumption: there was a * in the matcher column), or you get
> nothing (assumption: the style's not set at all); plus do some optimisation
> based on which completers don't use matching at all, to avoid calling
> completers unnecessarily.

Err, hadn't thought about putting that into _main_complete (where we
can optimise).

One last question: wouldn't it then be better to just have a
matcher-list style, taken as an array, containing the match specs to
try one after another?

> On the other discussion, I'm certainly not hung up on providing
> alternatives to the string context, which I think is pretty usable when you
> get your mind round it.  It's more a question of what the punters think
> than what I think.
> 
> By the way, should there be a style that says that old-style completions
> are to be used?  It would avoid the necessity of customizing _default.

Good idea. The patch does that and if the style is unset, compcall
will be used if the compctl module is loaded (so it should work
automatically for those who still have compctls). It can be explicitly 
turned off by setting the style to one of the `false' values, though.

Then I found another problem with compcall -- we need enable the
compctl module to clean up after completion since compcall may be
called. Yet another hook (or, more precisely, a old hook re-appearing).

Bye
 Sven

diff -ru ../z.old/Completion/Base/_default Completion/Base/_default
--- ../z.old/Completion/Base/_default	Wed Feb 16 11:15:32 2000
+++ Completion/Base/_default	Wed Feb 16 11:42:14 2000
@@ -1,16 +1,16 @@
 #compdef -default-
 
-# You can first try the `compctl's by uncommenting the `compcall' line
-# below.
-# This is without first (-T) and default (-D) completion. If you want
-# them add `-T' and/or `-D' to this command. If there is a `compctl'
-# for the command we are working on, we return immediatly. If you want
-# to use new style completion anyway, remove the `|| return'. Also,
-# you may want to use new style completion if the `compctl' didn't
-# produce any matches. In that case remove the `|| return' and insert
-# the line `[[ compstate[nmatches] -eq 0 ]] || return' after `compcall'.
+local ctl
 
-# compcall || return 0
+if { zstyle -s ':completion:${curcontext}:' use-compctl ctl ||
+     zmodload -e zsh/compctl } && [[ "$ctl" != (no|false|0|off) ]]; then
+  local opt
+
+  opt=()
+  [[ "$ctl" = *first* ]] && opt=(-T)
+  [[ "$ctl" = *default* ]] && opt=("$opt[@]" -D)
+  compcall "$opt[@]" || return 0
+fi
 
 _tags files || return 1
 
diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Wed Feb 16 11:15:21 2000
+++ Doc/Zsh/compsys.yo	Wed Feb 16 11:48:48 2000
@@ -1359,6 +1359,23 @@
 tt(all-files) plus all tags offered by the completion function will be 
 used.
 )
+item(tt(use-compctl))(
+If this style is set to a string not equal to tt(false), tt(0),
+tt(no), and tt(off), the completion system will use any completion
+specifications defined with the tt(compctl) builtin command. If the
+style is unset, this will only be done if the tt(zsh/compctl) module
+is loaded. The string may also contain the substring tt(first) to make
+the definition for tt(compctl -T) be used and the substring
+tt(default) to make the one for tt(compctl -D) be used.
+
+Note that this is only intended to smooth the transition from
+tt(compctl) to the new completion system and may disappear in the
+future.
+
+Note also, that the definitions from tt(compctl) will only be used if
+there is no special completion function for the command completion is
+done upon.
+)
 item(tt(users))(
 This may be set to a list of names that should be completed whenever 
 a username is needed. If it is not set or the string on the line
diff -ru ../z.old/Src/Zle/comp.h Src/Zle/comp.h
--- ../z.old/Src/Zle/comp.h	Wed Feb 16 11:15:12 2000
+++ Src/Zle/comp.h	Wed Feb 16 11:28:05 2000
@@ -364,7 +364,8 @@
 #define INSERTMATCHHOOK     (comphooks + 0)
 #define MENUSTARTHOOK       (comphooks + 1)
 #define COMPCTLMAKEHOOK     (comphooks + 2)
-#define COMPLISTMATCHESHOOK (comphooks + 3)
+#define COMPCTLCLEANUPHOOK  (comphooks + 3)
+#define COMPLISTMATCHESHOOK (comphooks + 4)
 
 /* compctl hook data struct */
 
diff -ru ../z.old/Src/Zle/compcore.c Src/Zle/compcore.c
--- ../z.old/Src/Zle/compcore.c	Wed Feb 16 11:15:12 2000
+++ Src/Zle/compcore.c	Wed Feb 16 11:38:04 2000
@@ -844,6 +844,9 @@
 	callcompfunc(s, compfunc);
 	endcmgroup(NULL);
 
+	/* Needed for compcall. */
+	runhookdef(COMPCTLCLEANUPHOOK, NULL);
+
 	if (oldlist) {
 	    nmatches = onm;
 	    validlist = 1;
@@ -891,6 +894,9 @@
 	dat.incmd = incmd;
 	dat.lst = lst;
 	runhookdef(COMPCTLMAKEHOOK, (void *) &dat);
+
+	/* Needed for compcall. */
+	runhookdef(COMPCTLCLEANUPHOOK, NULL);
 
 	return dat.lst;
     }
diff -ru ../z.old/Src/Zle/compctl.c Src/Zle/compctl.c
--- ../z.old/Src/Zle/compctl.c	Wed Feb 16 11:15:13 2000
+++ Src/Zle/compctl.c	Wed Feb 16 11:30:53 2000
@@ -1892,6 +1892,13 @@
     return 0;
 }
 
+static int
+cccleanuphookfn(Hookdef dummy, void *dat)
+{
+    ccused = ccstack = NULL;
+    return 0;
+}
+
 /* This adds a match to the list of matches.  The string to add is given   *
  * in s, the type of match is given in the global variable addwhat and     *
  * the parameter t (if not NULL) is a pointer to a hash node node which    *
@@ -3906,6 +3913,7 @@
 boot_(Module m)
 {
     addhookfunc("compctl_make", (Hookfn) ccmakehookfn);
+    addhookfunc("compctl_cleanup", (Hookfn) cccleanuphookfn);
     return (addbuiltins(m->nam, bintab, sizeof(bintab)/sizeof(*bintab)) != 1);
 }
 
@@ -3914,6 +3922,7 @@
 cleanup_(Module m)
 {
     deletehookfunc("compctl_make", (Hookfn) ccmakehookfn);
+    deletehookfunc("compctl_cleanup", (Hookfn) cccleanuphookfn);
     deletebuiltins(m->nam, bintab, sizeof(bintab)/sizeof(*bintab));
     return 0;
 }
diff -ru ../z.old/Src/Zle/complete.c Src/Zle/complete.c
--- ../z.old/Src/Zle/complete.c	Wed Feb 16 11:15:13 2000
+++ Src/Zle/complete.c	Wed Feb 16 11:27:42 2000
@@ -1288,6 +1288,7 @@
     HOOKDEF("insert_match", NULL, HOOKF_ALL),
     HOOKDEF("menu_start", NULL, HOOKF_ALL),
     HOOKDEF("compctl_make", NULL, 0),
+    HOOKDEF("compctl_cleanup", NULL, 0),
     HOOKDEF("comp_list_matches", ilistmatches, 0),
 };
 

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

RE: 3.1.6-dev-18

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> ...
> 
> When I spoke about array, I meant absolutely different thing. Remove
> _matcher completer alltogether. Setup a style with match specs, that will be
> tried in order. In other words
> 
> zstyle :completion::complete::::: match_specs "" spec1 spec2 ...
> 
> with semantics
> 
> _complete should try this list in order until it gets matches.

Currently it is only _complete. But noone knows if in the future we
may have other completers that could take advantage of match specs.

Also, if we put it into _complete, you'll always get the match specs -- 
if it is called from _main_complete or _prefix or from whereever
else (so we would at least have to make it test if we are currently
doing correction or approximation and avoid the loop then). In other
words, controlling the match specs would -- in my opinion -- be even
less obvious than it is now.

> I agree, that your way provides more fine grained control ... the question
> is, how complex completion system is going to be? Do you think, that an
> everage user would ever need such a complexity?

`need' is a dangerous word... I think users would like to be able to
control exactly when which match specs are used, even if only for
performance reasons. I'm planning to go through the manual at least
once more (and through Peter's guide when it's there), trying to make
things like this clearer (more examples, at least).

> And what occured to me ... why _oldlist, _prefix etc are completers at all?
> They look much more like actually a styles to me! They do not generate any
> matches - rather, they say completion system _how_ to generate matches. So,
> somewhat revolutionary ;-) idea:

Well, since _prefix calls the completers one could say that it does
generate matches -- in the same way _correct and _approximate do.

For things like _oldlist... it's mostly a matter of trying to make
things cleaner and cheaper. Putting things that are similar into a
separate module instead of having one monster-module that can do
everything (otherwise we could just have a builtin with lots of
options...). And putting things into separate functions means that
only people that *want* the behaviour have to pay for it, at least in
terms of execution speed.


Bye
 Sven

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

Re: 3.1.6-dev-18

[Peter Stephenson]

Sven Wischnowsky wrote:
> Peter Stephenson wrote:
> 
> > zstyle ':completion:*' completer _matcher ....
> > zstyle ':completion:*' matcher blah1 blah2 ...
> 
> This would have a different effect... See 9657 and follow-ups (or the
> docs). It's something like:
> 
>   zstyle ... completer _matcher _complete _matcher _complete ...
>   zstyle ':completion:*:matcher-1:*' matcher blah1
>   zstyle ':completion:*:matcher-2:*' matcher blah2
> 
> If this looks weird to anyone, please join the discussion in 9678,
> 9679 and tell us what you think about what I said in the latter.

It took me a while to work out what you were saying, but I think it's that
while `blah1 blah2' used to be tried one after another when they were
elements of $compmatchers, they get tried all at once if they are elements
of the matcher style in the form I gave it.  If that's correct, I doubt if
that's a major issue for most users --- I suspect that most people who used
more than one element of $compmatchers just had different things in them,
as I did.

Still, how much do you gain by being able to put them in matcher-1 and
matcher-2?  Is that more powerful than just using array elements of the
style in order, rather than simply more cumbersome?  The only examples I
can think of where you gain something are where _matcher is followed the
second time by _prefix instead of _complete (or vice versa), or where some
other element of the context is different between the matcher-1 and
matcher-2 cases.  These seem to me to be to abstruse to be useful.  But I
may well have missed something.

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

Re: 3.1.6-dev-18

[Sven Wischnowsky]

Peter Stephenson wrote:

> Beta testers not following everything in detail should notice that
> $compmatchers has been replaced by a completer and a style.  Namely, to do
> 
> compmatchers=(blah1 blah2 ...)
> 
> instead do
> 
> zstyle ':completion:*' completer _matcher ....
> zstyle ':completion:*' matcher blah1 blah2 ...

This would have a different effect... See 9657 and follow-ups (or the
docs). It's something like:

  zstyle ... completer _matcher _complete _matcher _complete ...
  zstyle ':completion:*:matcher-1:*' matcher blah1
  zstyle ':completion:*:matcher-2:*' matcher blah2

If this looks weird to anyone, please join the discussion in 9678,
9679 and tell us what you think about what I said in the latter.

Bye
 Sven


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

3.1.6-dev-18

[Peter Stephenson]

I have uploaded
  ftp://ftp.zsh.org/zsh/development/zsh-3.1.6-dev-18.tar.gz

This now *does* include zpty, despite possible configuration problems, and
I haven't yet got around to implementing --exclude-modules in configure.
It omits a couple of make patches from Adam (i.e. even the latest versions
of same) about which there were quibbles.

Beta testers not following everything in detail should notice that
$compmatchers has been replaced by a completer and a style.  Namely, to do

compmatchers=(blah1 blah2 ...)

instead do

zstyle ':completion:*' completer _matcher ....
zstyle ':completion:*' matcher blah1 blah2 ...

(see the docs for more).

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

	* pws: Config/version.mk: 3.1.6-dev-18

	* Tanaka Akira: 9683: Completion/User/_diff_options: shut up error
	messages (after other attempts from Oliver and Bart).

	* Alexandre: 9681: Completion/User/_prcs: argument handling.

	* Sven: 9680: Completion/Core/_files,
	Completion/Core/_multi_parts, Completion/Core/_path_files,
	Completion/Core/_sep_parts: use of -M option.

	* Sven: 9677, 9679: Completion/Commands/_read_comp,
	Completion/Core/_approximate, Completion/Core/_expand,
	Completion/Core/_main_complete, Completion/Core/_match,
	Doc/Zsh/compctl.yo, Doc/Zsh/compsys.yo, Doc/Zsh/compwid.yo,
	Src/Zle/comp.h, Src/Zle/compcore.c, Src/Zle/compctl.c,
	Src/Zle/complete.c: $compmatchers bites the dust, use new matcher
	style.

	* Sven: 9676: Src/Zle/computil.c: yet more argument subtleties.

	* Tanaka Akira: 9674: Test/10prompt.ztst: some nameless idiot got
	the bits of the date wrong.

	* Sven: 9664: Completion/Core/_path_files: optimisation with
	arrays.

	* Sven: 9659: Doc/Zsh/compsys.yo: mention complete-in-words
	behaviour.

	* Sven: 9657: Completion/Core/_approximate,
	Completion/Core/_description, Completion/Core/_main_complete,
	Completion/Core/_matcher, Completion/Core/_path_files,
	Completion/Core/_prefix, Doc/Zsh/compsys.yo, Src/Zle/complete.c
	(plus Completion/Core/.distfiles change by hand): new _matcher
	completer allows more control along the lines of $compmatchers.

	* Johan: 9653: Functions/Misc/is-at-least,
	Functions/Misc/.distfiles (added by hand): function to check
	version numbers.

	* Johan: 9651: Completion/User/_cvs: handle no CVS tags case better.

	* Sven: 9650: Completion/User/_gunzip, Completion/User/_gzip:
	handle .tgz files.

	* Sven: 9648: Completion/Core/_files,
	Completion/Core/_multi_parts, Completion/Core/_path_files,
	Completion/Core/_sep_parts, Doc/Zsh/mod_zutil.yo,
	Src/Modules/zutil.c: Bartised version of zparseopts;
	fix _path_files -S ''.

	* Bart: 9639: Doc/Zsh/options.yo, Doc/Zsh/redirect.yo: typos in
	9625.

	* Tanaka Akira: 9638: Completion/User/_cvs: _cvs_rtag had no
	default implementation.

	* Sven: 9635: Completion/Core/_description,
	Completion/Core/_files, Completion/Core/_multi_parts,
	Completion/Core/_path_files, Completion/Core/_sep_parts,
	Doc/Zsh/mod_zutil.yo, Src/Modules/zutil.c, Src/Modules/zutil.mdd:
	improved performance for completion functions; option-parsing
	builtin.

	* Akim Demaille <akim@epita.fr>: 9634: Src/builtin.c: trap '' 1
	segfaulted.

	* Sven: 9633: Src/init.c: change logic in 9591.

	* Sven: 9632: Test/05command.ztst: error spotted by improved
	autoload error checking.

	* Alexandre: 9625: Src/zsh.h, Src/options.c, Src/init.c,
	Src/exec.c, Doc/Zsh/redirect.yo, Doc/Zsh/options.yo: SHNULLCMD and
	CSHNULLCMD options to allow better sh/csh emulation without
	fiddling with parameters.

	* Sven: 9623: Completion/Core/_path_files: another version of
	9616.

	* Sven: 9621: Src/Zle/computil.c: completion incorrectly adding
	space.

	* Sven: 9619: Completion/User/_texi: completion for texinfo;
	added Completion/User/.distfiles by hand.

	* Sven: 9618: Src/Zle/computil.c: memory leak in caching.

	* Sven: 9616: Completion/Core/_path_files: bad test with a
	pattern.

	* Sven: 9615: Completion/Builtins/_zstyle, Doc/Zsh/compsys.yo:
	rename and document some styles.

	* Sven: 9614: Src/exec.c: esglob wasn't initialised properly.

	* Alexandre: 9606: Completion/Builtins/_zstyle: two missing
	styles.

	* Sven: 9600: Src/exec.c: wordcode problem in execpline().

	* Bart: 9591: Src/init.c: zsh/compctl didn't get loaded
	automatically any more.

	* Geoff: 9589: Doc/Makefile.in: put back ^A's from 9584.

	* Tanaka Akira: 9585: Doc/Makefile.in: possible logic problems
	with 9584.

	* Geoff: 9584: Doc/Makefile.in: sh problems with creating
	modlist.yo.

	* Alexandre: 9583: Functions/Misc/nslookup: fix context name for
	new scheme.

	* Sven: 9390, 9394, hunk from 9396: ./Doc/Makefile.in,
	Doc/Zsh/mod_zpty.yo, Doc/Zsh/.distfiles, Functions/Misc/nslookup,
	Src/Modules/.distfiles, Src/Modules/zpty.c, Src/Modules/zpty.mdd,
	Src/builtin.c, Src/init.c, Src/zsh.h: zpty module.

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

	* Tanaka Akira: 9579: Completion/Debian/_deb_packages: was using
	bad cache variable.

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

	* Sven: 9569: Completion/Core/_main_complete,
	Completion/Core/_prefix, Doc/Zsh/compsys.yo, Src/Zle/compcore.c:
	new complete-prefix completer _prefix; fix suffix matching
	problems.

	* Sven: 9568: Src/Zle/computil.c: fix difficulties with remaining
	arguments.

	* Sven: 9562: Completion/Base/_arg_compile,
	Completion/Base/_arguments, Completion/Base/_command_names,
	Completion/Builtins/_hash, Completion/User/_gdb,
	Completion/User/_ssh, Completion/User/_strip, Completion/X/_xrdb,
	Completion/X/_xutils, Src/Zle/computil.c: failure to follow links
	completing commands; bad long option handling in some cases

	* Sven: 9560 (second hunk only): Src/Zle/computil.c: more
	argument fixes.

	* Sven: 9559: Doc/Zsh/compsys.yo: better documentation for `+'
	argument handling.

	* Sven: 9558: Src/exec.c, Src/parse.c: trapping of autoloading
	errors wasn't up to scratch.

	* Alexandre: 9557: Completion/User/_flex: problem handling
	`+' argument.

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

	* Oliver: 9547: Src/parse.c, Src/hist.c: more fixups for exporting
	on AIX.

	* Sven: 9546: Completion/Base/_arguments,
	Completion/Base/_combination, Completion/Base/_describe,
	Completion/Base/_first, Completion/Base/_jobs,
	Completion/Base/_subscript, Completion/Base/_tilde,
	Completion/Base/_values, Completion/Builtins/_pids,
	Completion/Builtins/_popd, Completion/Builtins/_sched,
	Completion/Builtins/_signals, Completion/Builtins/_stat,
	Completion/Builtins/_zftp, Completion/Builtins/_zstyle,
	Completion/Commands/_complete_help,
	Completion/Commands/_correct_word,
	Completion/Commands/_expand_word,
	Completion/Commands/_history_complete_word,
	Completion/Core/_alternative, Completion/Core/_approximate,
	Completion/Core/_complete, Completion/Core/_correct,
	Completion/Core/_description, Completion/Core/_expand,
	Completion/Core/_files, Completion/Core/_list,
	Completion/Core/_main_complete, Completion/Core/_match,
	Completion/Core/_menu, Completion/Core/_message,
	Completion/Core/_normal, Completion/Core/_oldlist,
	Completion/Core/_path_files, Completion/Core/_setup,
	Completion/Core/_sort_tags, Completion/Core/_tags,
	Completion/Core/compinit, Completion/Debian/_apt,
	Completion/Debian/_deb_packages, Completion/User/_cvs,
	Completion/User/_domains, Completion/User/_groups,
	Completion/User/_hosts, Completion/User/_ports,
	Completion/User/_socket, Completion/User/_urls,
	Completion/User/_users, Completion/X/_x_color, Doc/Zsh/compsys.yo,
	Etc/completion-style-guide,
	Functions/Zle/incremental-complete-word, Functions/Zle/predict-on:
	more consistent form for style contexts in completion system,
	:completion:<func>:<completer>:<command>:<argument>:<tag>.

	* Sven: 9545: Src/Modules/zutil.c: don't use freed structs.

	* Tanaka Akira: 9544: Src/Modules/zutil.c: handle case for
	undefined match data in zregexparse.

	* Sven: 9542: Src/Zle/complete.c: use permanently allocated memory
	for copied special parameters.

	* Sven: 9541: Src/Modules/zutil.c: zstyle looks up style names
	first.

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