Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> I'd better leave zle -c to Sven, since I haven't had much time to look
> at all the details.  I mentioned some time ago I was unhappy about the
> setting/unsetting of the existing zle parameters like $BUFFER, which
> still needs looking at, I don't know if it applies to Sven's new ones.

I remember that there was  aproblem, but don't remember which, we'll see...

> ...
> 
> So I would propose simply removing zle -C, and being ready to document
> various how-to's in the compctl manual when the new stuff becomes
> fixed.  It hasn't been in any archived version, so I hope there won't
> be many cries of woe.

Hm, your stuff is still simpler (although I'd like to inherit the
upper case `C' ;-).
 
> By the way: I stumbled on compadd -p ${match:h}/ -f ${match:t}
> to get the listing to work the way it normally does for files.  Is
> this the approved way, or is the something better?

Yes, this is what I expected, but I'll comment in this in my reply
which I'm working on.

Bye
 Sven


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

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Sven Wischnowsky]

Bart Schaefer wrote:

> X-Seq: 5087
> 
> On Jan 28, 12:28pm, Peter Stephenson wrote:
> } Subject: Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
> }
> } I'm increasingly of the opinion we can do without zle -C.  [...]
> } So I would propose simply removing zle -C, and being ready to document
> } various how-to's in the compctl manual when the new stuff becomes
> } fixed.  It hasn't been in any archived version, so I hope there won't
> } be many cries of woe.
> 
> Sounds fine to me (and would give over to Sven the "-C" option).  As I
> said elsewhere, I don't think anybody running any version of 3.1.x has
> much call for woeful cries; the whole point of a development version is
> to be able to change stuff until it works right.  (3.0.x users are
> another matter, but not at issue here.)

Two more comments:

- complist currently accepts only simple flag lists, nothing of the
  complicated stuff (-x, +, -l '', and a few more), since that would
  require setting up things like the word-array each time complist is
  used. We could do that (the code is there and used for `compcall')
  but it would make things a bit slower (in some simple cases we can
  quickly test if we need to set up things and thus sometimes avoid
  doing so, but sometimes this test would be complicated).
  Whereas `-C' accepts anything `compctl' accepts.
- After looking again at Peter's examples (the ones he converted from
  `zle -C' to `zle -c') I'd like to point out that we could even
  supply a shell function that creates such one-shot completion
  widgets. So, that may be an argument for removing it...

Bye
 Sven


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

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Bart Schaefer]

On Jan 28, 12:28pm, Peter Stephenson wrote:
} Subject: Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
}
} I'm increasingly of the opinion we can do without zle -C.  [...]
} So I would propose simply removing zle -C, and being ready to document
} various how-to's in the compctl manual when the new stuff becomes
} fixed.  It hasn't been in any archived version, so I hope there won't
} be many cries of woe.

Sounds fine to me (and would give over to Sven the "-C" option).  As I
said elsewhere, I don't think anybody running any version of 3.1.x has
much call for woeful cries; the whole point of a development version is
to be able to change stuff until it works right.  (3.0.x users are
another matter, but not at issue here.)

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

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Sven Wischnowsky]

Bart Schaefer wrote:

> Could somebody who's managed to keep track of all this stuff (Sven?  Peter?)
> please post a complete summary for _both_ zle -c and zle -C of
> 
>   * the new commands (compadd, complist, compcall, etc.)
>   * the new variables (what's in them and when they're available)
>   * the parameters passed to a user's shell functions in each case
> 
> Unfortunately, I haven't had time to study Sven's posts enough to do it.
> 
> A whole lot of stuff has gone by recently that sounds good in the abstract
> but that feels, in Sven's words, "rather hackish."  If it were all written
> down in one place it might become obvious how it could all be made to fit
> together better.

Well...

New style completion stuff:

  zle -c name comp func

This defines a widget named `name' that calls the shell function
`func' to produce matches. All the other things completion does, like
displaying a list, deciding what to insert in the line, deciding if
menu-completion should be used and so on is currently only controlled
by the C-code. To allow the user to say how he would like this widget
to behave, (s)he has to give the name of one of the builtin
completion-widgets as the `comp' argument, e.g.:

  zle -c my-comp expand-or-complete my-comp-func

Defines the widget `my-comp', makes it call the shell function
`my-comp-func' and makes the completion code behave as if
`expand-or-complete' were used.

Now, inside the shell function the completion code sets up some
variables and offers a few extra builtins and condition codes (the
stuff below is copied and updated from message 4850):


The parameters are:

  PREFIX   the prefix of the current word from the command line
  IPREFIX  an ignored prefix (see below)
  SUFFIX   the suffix of the current word
  COMMAND  this is something like the `direct context'; for completion 
           of arguments it contains the command name, but for
	   subscripts or when completion the right hand side of a
	   parameter assignment this holds the name of the parameter;
	   also, when completing a redirection, this holds the
	   redirection operator itself (the command is still in argv)
  CONTEXT  the context we are currently completing in, this can be
           any of:

             `command'   we are completing in command position
             `argument'  we are completing in argument position
	     `redirect'  ... after a redirection operator
	     `math'      ... in a math environment
	     `subscript' ... in a subscript
	     `value'     ... in the value of an variable assignment
	     `condition' ... inside `[[...]]'

  argv     if completing an argument this holds the argument strings
           (not including the command name); when completing an
	   redirection it contains the command line strings (including 
	   the command name); when completing on the right hand side
	   of an array assignment this holds the strings in the
	   parentheses
  CURRENT  this is the index into `argv' pointing to the current word
  NMATCHES this is the number of matches produced (and accepted) so far

These variables are settable, the example file contains two convenient 
aliases to save and restore them. The completion code uses a wrapper
function to reset them to their old values at the end of each function
executed from the completion widget.


The conditions work on the contents of these variables, probably
changing them, they are modeled directly after the `compctl -x'
condition code:

  -prefix str
     is true if PREFIX starts with str

  -iprefix str
    like `-prefix', but makes the matched portion be
    ignored; this is done by appending the matched
    portion to IPREFIX and removing it from PREFIX

  -position beg [end]
    is true if we are currently in position `beg' (or between `beg'
    and `end' if that is given); if `end' is given COMMAND, CONTEXT,
    CURRENT, and argv are changed so that they contain only the range
    of words between these positions
    (as always when one of these condition takes an integer argument
    an expression may be given, like `-position a+1')

  -word index str
    is true if the `index'th argument is `str'

  -mword index pat
    like `-word' but with pattern matching

  -current index str
  -mcurrent index pat
    like `-word' and `-mword' but the `index' is take relative to the
    current position

  -string str
  -string index str
    true if the current word contains `str'; anything up to the
    `index'th occurrence of `str' is ignored (or anything up to the
    last occurrence if no `index' is given, again this sets IPREFIX
    and PREFIX)

  -class str
  -class index str
    like `-string' but the `str' is taken as a character class

  -words min [max]
    true if we have at least `min' arguments (and less than or equal
    to `max' arguments if that is given)

  -between s1 s2
    true if we are between an argument equal to `s1' and before an
    argument equal to `s2' (if there is such an argument)

  -mbetween p1 p2
    like `-between' but with pattern matching

  -after str
    true if we are after an argument equal to `str'

  -mafter pat
    like `-after' but with pattern matching

  -nmatches num
    true if we have generated `num' matches

Of course, tests can also be done by using the normal condition stuff
and the above variables (probably changing them), but these condition
codes may be faster and/or easier to use.


The builtins are:

complist ...

  This gets almost the same arguments as compctl, except the more
  complicated ones (like xor'ed completions, `-x', `-l', ...).
  When using this builtin, the completion code uses the current values
  of the variables above, so that the combination of this builtin and
  the condition codes makes life really simple...

compadd [options] matches...

  This allows access to the structure used internally used for storing 
  matches. When using this builtin the variables are not used and the
  completion code does not check if the strings added match what is
  one the command line, so you should know what you are doing.

  Supported options are:

    -q, -Q, -U, -P str, -S str, -J name, -V name
      these are used like the options with the same names in compctl and 
      complist

    -f 
      if this option is given the strings are treated like filenames
      (showing files types with LISTTYPES)

    -a
      this says to put the matches in the alternative set (those that
      are build for fignore ignored)

    -n
      this keeps the strings from appearing in the list of matches

    -i str
      this gives an ignored previous to use when inserting the match;
      such a string is not listed and inserted before a prefix given
      with the `-p' option

    -p str
      this gives another prefix that is not listed; but it is inserted 
      and used for testing file types

    -s str
      like `-p' but giving a suffix

  When I announced all this I said that this is least stable part of
  the new completion stuff because I hadn't had the time to check most 
  of this. Now, the example file contains a function that heavily uses 
  this builtin and seems to work fine.
  It is intended as a utility to give full control to the things stored 
  for each match. I would like to add some more functionality to make
  it easier to use for things people can be expected to want to have.
  For example:

  - a flag that says that the matches are filenames and that makes the 
    code automatically check fignore; this could also automatically
    try to list only path name components and the like (but I think we 
    an extra option to support this would be better, since the results 
    may probably be unexpected or unwanted)

  - a flag that says that normal matching rules should be applied
    (together with support for the `-M' option known from compctl and
    complist); this is important to have since currently all words
    given to compadd are taken even if they don't match what's on the
    line, so you have to do all the matching yourself (which can get
    complicated if you use `-M'); also, this isn't that hard to add
    since most of the code is already there

  - a way to specify when a added -S-suffix should be removed
    (i.e. after which characters are typed should the suffix be
    removed)

  Of course, other things may also turn out to be interesting, we'll
  see.

compcall [ -[TD] ]

  This is the youngets of the builtins. It allows to call the
  `compctl'-stuff from a new style completion widget. It takes no
  arguments, only two options. Normally, `compctl -T' and `compctl -D'
  are not used when calling `compctl's, since I expect this to be used
  mainly for command-`compctl's. However, if you want them to be used
  you can give the respective option to `compcall' and you'll get them 
  used. The completion code called is made to believe that the line
  looks like the stuff described in the parameters above (PREFIX,...).
  For this we needed some conversion and copying-around which may not
  be fully correct yet (so here is some code that at least needs some
  verifying, more likely some changes).
  If this turns out to be interesting enough to stay alive (and I
  almost expect it to be), there are many things we might to want add
  or change, e.g.:

  - make it take arguments which are to be taken as the words the
    `compctl'-code should think are on the command line
  - let it accept options with strings for the stuff which is
    currently taken from the parameters
  - for now, the status-return is always zero, it may be interesting
    or even important to let it return some useful things; this can be 
    information about continuing (`compctl -t<c>'), some kind of
    signal if a compctl has been processed, and so on.
  
compctl -K ' foo'

  This is as hackish as can be. This special syntax (note the space
  before the function name `foo') currently allows us to call `foo'
  from `compctl'-code in the same way as new style completion widgets
  are called, i.e. with the parameters set up and allowed to call
  `complist', `compadd', and `compcall'. I didn't bother to search a
  free option character for it (although, if I remember correctly,
  there still was one, but not many more than one), because I'm not
  too convinced, that we should support this, although I admit that it 
  may be interesting to have in some cases. But we may as well keep
  it, especially since this (currently) adds only two lines of code.


The examples in `new-completion-examples':

  This file contains all the code you need to try all this new
  completion stuff, including the definition of a completion widget
  and the call to `bindkey' to bind it to TAB.

  It has two functions to define completion handlers, `defcomp' and
  `defpatcomp', where the first defines a handler for commands or one
  of the special contexts (like `subscript') and the second one
  defines handlers that should be used when the command name matches a 
  given pattern.

  The master function of the code is `main-complete'. It first calls
  `compcall' to get access to the old `compctl's, then calls the
  equivalent of `-T' and finally has a look at CONTEXT to find out
  which handler it should call. If you are completing a command or
  argument, `do-complete' is called to handle that, finding matching
  patterns and normal handlers or the equivalent of `-D'. This also
  emulates the `use last path-name component' and the `=' special
  handling done by the `compctl'-completion code.

  To really call the handler, `call-complete' is invoked. This looks
  up the definition, which may be a array name or a function name. If
  it is a function, it is called (and will use `complist', `coompadd', 
  and friends). If it is an array, `complist' is called with the
  contents of the array as arguments. This allows one to keep simple
  definitions simple, as in:

    defcomp __command --command--
    __command=( -c )

  For the functions there are some helpers:

    - `compsave' and `compreset' can be used to save and restore the
      states of the special parameters; this is important to have when 
      using the conditions and if you want to make more than one test
      in the same function
    - `compsub' calls `do-complete' again with the current settings of 
      the special parameters; this is the replacement for `compctl -l'
    - `compalso' can be used to add the matches for another command or 
      special context (intended for e.g. `subscript includes math')
    - `pfiles' does partial-path completion. It gets no arguments or
      one of `-f', `-/', or `-g' known from `compctl'. If you use `-g' 
      the patterns to search should be given after the `-g', one per
      argument (*not* all in one string). As its first two arguments,
      it accepts `-W <paths>' where `<paths>' looks like the things
      you can give to `compctl -W'. With all this, `pfiles' is
      intended as a replacement for `comp{ctl,list} -[f/g]', giving
      you multicomp-like partial path completion everywhere.
    - `files' just calls `pfiles' with the arguments it got and, if
      that doesn't produce any matches, calls `pfiles' again with no
      arguments, producing all filenames. This is a replacement for
      `compctl -[f/g] ... + -f'.
      Yes, this could do with some work...

  One thing that is not yet correct is the continuation-stuff. The
  main functions use the return values of the handler functions for
  this: zero means that other handlers should be tried, non-zero means 
  that no more matches should be produced. I still have to check all
  the example handler functions if they behave correctly with respect
  to this.


Mixed comments (most of them are from the old message):

- I haven't used an associative array for the variables since I would
  then like to put [LR]BUFFER and so on into it and I didn't want to
  change to many parts of the shell for this first version.
  Also: using separate variables makes handling them so easy...
- When using `complist' the completion code still does normal completion 
  after `~', `=', and `$' (unless that is in IPREFIX, of course).
- Later we may add a way to access the matches produced and to control 
  what is done with the collected data (inserting, listing, ...)
- With `complist' you can make functions be called with `-K' and `-y'
  put they can't use `read' to get at the comamnd line data. This is
  because the new style completion uses a different way to store them
  (the above parameters).
- When using conditions that change the parameter values the behavior
  may be irritating since following tests use the changed values. To
  avoid this you have to put the test into a separate function so that
  the previous state is automatically restored by the completion code
  or you have to restore the state by hand. Since I expect that many
  users will want to put all their tests for a command in one function
  (making things better readable) restoring by hand and forgetting to
  do so in the right places will become inconvenient. This is the
  reason for the `compsave' and `compreset' helper aliases, I *really* 
  would like to find a way to take this burden from the user.
- The condition codes behave a bit different from their `compctl -x'
  counterparts since they can only access the arguments (not the
  command name).
- The attentive reader of the patch will notice some hunks in zsh.h
  and in mem.c. This implement a way to re-use older heaps. In fact
  there are functions that allow one to temporarily switch to another
  heap, go back to an older heap, and to temporarily switch to another 
  heap. The patch for zsh.h implements some macros like HEAPALLOC that 
  make it easy to use this mechanism.
- The value of `COMMAND' may be a bit irritating, since it depends on
  the `CONTEXT', we might want to rename it, change it, add another
  one, or something like that.

Ok, I hope this helps for now.

Bye
 Sven

P.S.: So long a message, and not even a patch, tststs ;-)

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

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Peter Stephenson]

"Bart Schaefer" wrote:
> Could somebody who's managed to keep track of all this stuff (Sven?  Peter?)
> please post a complete summary for _both_ zle -c and zle -C of
> 
>   * the new commands (compadd, complist, compcall, etc.)
>   * the new variables (what's in them and when they're available)
>   * the parameters passed to a user's shell functions in each case

I'd better leave zle -c to Sven, since I haven't had much time to look
at all the details.  I mentioned some time ago I was unhappy about the
setting/unsetting of the existing zle parameters like $BUFFER, which
still needs looking at, I don't know if it applies to Sven's new ones.

I'm increasingly of the opinion we can do without zle -C.  All the
uses I have for it can be replaced; I've just quickly converted my
current list of zle -C's into (this uses the new glob
sorting/selecting mechanism, too):

  zle -c history-complete-word complete-word __history_complete_word
  __history_complete_word() { complist -Q -H 0 ''; }
  bindkey "\e/" history-complete-word
  bindkey "\M-/" history-complete-word

  zle -c most-recent-file complete-word __most_recent_file
  __most_recent_file() {
    local match
    if [[ $PREFIX = *\** ]]; then
      match=(${~PREFIX}${~SUFFIX}(Om[1]))
    else
      match=(${~PREFIX}*${~SUFFIX}(Om[1]))
    fi
    [[ -n $match ]] && compadd -p ${match:h}/ -f ${match:t}
  }
  bindkey "\C-x." most-recent-file

  zle -c complete-filename complete-word __complete_filename
  __complete_filename() { complist -f; }
  bindkey "\C-xf" complete-filename

  zle -c complete-directory complete-word __complete_directory
  __complete_directory() { complist -/; }
  bindkey "\C-x\C-d" complete-directory

So I would propose simply removing zle -C, and being ready to document
various how-to's in the compctl manual when the new stuff becomes
fixed.  It hasn't been in any archived version, so I hope there won't
be many cries of woe.

By the way: I stumbled on compadd -p ${match:h}/ -f ${match:t}
to get the listing to work the way it normally does for files.  Is
this the approved way, or is the something better?

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Bart Schaefer]

Could somebody who's managed to keep track of all this stuff (Sven?  Peter?)
please post a complete summary for _both_ zle -c and zle -C of

  * the new commands (compadd, complist, compcall, etc.)
  * the new variables (what's in them and when they're available)
  * the parameters passed to a user's shell functions in each case

Unfortunately, I haven't had time to study Sven's posts enough to do it.

A whole lot of stuff has gone by recently that sounds good in the abstract
but that feels, in Sven's words, "rather hackish."  If it were all written
down in one place it might become obvious how it could all be made to fit
together better.

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

RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> >   `compcall' accepts no other option or argument, for now. It would
> >   be easy to make it accept arguments for the command line words to
> >   use, for the command name to use, etc. If this turns out to be
> >   interesting to have, I'll add it.
> 
> I won't be able to test it for some time, but this occured to me today:
> 
> compctl -T -K " __default"
> 
> function __default() {
> 	compcall -T
> }

Damn. Yesterday I thought about this, but today I forget to handle
it. Since there is no easy way to correctly avoid recursions, let's
use a depth counter (until we find a better solution, if we ever find
a better solution).

Bye
 Sven

--- os/Zle/zle_tricky.c	Wed Jan 27 16:16:32 1999
+++ Src/Zle/zle_tricky.c	Wed Jan 27 16:18:58 1999
@@ -3449,10 +3449,21 @@
     } SWITCHBACKHEAPS;
 }
 
+/* A simple counter to avoid endless recursion between old and new style *
+ * completion. */
+
+static int cdepth = 0;
+
+#define MAX_CDEPTH 16
+
 /**/
 void
 makecomplistctl(int flags)
 {
+    if (cdepth == MAX_CDEPTH)
+	return;
+
+    cdepth++;
     SWITCHHEAPS(compheap) {
 	HEAPALLOC {
 	    int ooffs = offs, lip, lp;
@@ -3488,6 +3499,7 @@
 	    clwpos = op;
 	} LASTALLOC;
     } SWITCHBACKHEAPS;
+    cdepth--;
 }
 
 /* This function gets the compctls for the given command line and *

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

RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Andrej Borsenkow]

Oh, great man!

>   `compcall' accepts no other option or argument, for now. It would
>   be easy to make it accept arguments for the command line words to
>   use, for the command name to use, etc. If this turns out to be
>   interesting to have, I'll add it.
> 

I won't be able to test it for some time, but this occured to me today:

compctl -T -K " __default"

function __default() {
	compcall -T
}

/andrej

RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> What I think about, is two interfaces: compctl->new completion and new
> completion->compctl. That is

The patch below implements this:

new->old:

  The builtin `compcall' can be called from a new style completion
  function and makes the `compctl's for the current settings of
  COMMAND, IPREFIX, PREFIX, SUFFIX, and argv be used. Currently this
  builtin accepts only to options: `T' and `D'. Without any options
  the `compctl's for first completion (`-T') and for default (`-D')
  completion are *not* tried. You can switch this on by using the
  appropriate option.
  `compcall' accepts no other option or argument, for now. It would
  be easy to make it accept arguments for the command line words to
  use, for the command name to use, etc. If this turns out to be
  interesting to have, I'll add it.

old->new:

  I'm not too sure that I like to support this way, so this is rather
  hackish at the moment (meaning: even more than the rest of the new
  style completion). If you give the `-K' option to `compctl' a string 
  that begins with one space, the named function will be called with
  the variables and arguments as expected by new style completion
  functions.

Ok. Even though I said that this is very experimental, I strongly
suggest to use this patch. First, it makes testing the new stuff
easier, and second, the patch contains also a minor fix (compadd now
accepts zero arguments).

The patch also changes the file `new-completion-examples' to use
`compctl's that are defined. With that you should be able to just
source this file, use the new completion stuff and still be able to
use your `compctl's. You may want to modify or delete some of the
examples in the file. You may also want to alter the way compcall is
invoked, see the comments in the file after applying this patch (or
look at the end of this patch).

[The patch looks big, but this is almost only because it contains a
lot of moving-code-around and re-indent-stuff.]

Bye
 Sven

diff -u os/Zle/comp.h Src/Zle/comp.h
--- os/Zle/comp.h	Tue Jan 26 14:24:21 1999
+++ Src/Zle/comp.h	Wed Jan 27 11:14:43 1999
@@ -267,3 +267,8 @@
 #define CLF_MISS  4
 #define CLF_DIFF  8
 #define CLF_SUF  16
+
+/* Flags for makecomplist*(). Things not to do. */
+
+#define CFN_FIRST   1
+#define CFN_DEFAULT 2
diff -u os/Zle/compctl.c Src/Zle/compctl.c
--- os/Zle/compctl.c	Tue Jan 26 14:24:21 1999
+++ Src/Zle/compctl.c	Wed Jan 27 12:07:24 1999
@@ -1677,7 +1677,7 @@
     Compctl cc;
     int ret = 0;
 
-    if (!incompfunc) {
+    if (incompfunc != 1) {
 	zerrnam(name, "can only be called from completion function", NULL, 0);
 	return 1;
     }
@@ -1706,7 +1706,7 @@
     char *pre = NULL, *suf = NULL, *group = NULL;
     int f = 0, q = 0, m = 0, ns = 0, a = 0;
 
-    if (!incompfunc) {
+    if (incompfunc != 1) {
 	zerrnam(name, "can only be called from completion function", NULL, 0);
 	return 1;
     }
@@ -1800,6 +1800,15 @@
     return 0;
 }
 
+/**/
+static int
+bin_compcall(char *name, char **argv, char *ops, int func)
+{
+    makecomplistctl((ops['T'] ? 0 : CFN_FIRST) |
+		    (ops['D'] ? 0 : CFN_DEFAULT));
+    return 0;
+}
+
 #define VAR(X) ((void *) (&(X)))
 static struct compparam {
     char *name;
@@ -1855,7 +1864,7 @@
 static int
 comp_wrapper(List list, FuncWrap w, char *name)
 {
-    if (!incompfunc)
+    if (incompfunc != 1)
 	return 1;
     else {
 	char *octxt, *ocmd, *opre, *osuf, *oipre;
@@ -1906,7 +1915,7 @@
 static int
 comp_check(void)
 {
-    if (!incompfunc) {
+    if (incompfunc != 1) {
 	zerr("condition can only be used in completion function", NULL, 0);
 	return 0;
     }
@@ -2118,7 +2127,8 @@
 static struct builtin bintab[] = {
     BUILTIN("compctl", 0, bin_compctl, 0, -1, 0, NULL, NULL),
     BUILTIN("complist", 0, bin_complist, 1, -1, 0, NULL, NULL),
-    BUILTIN("compadd", 0, bin_compadd, 1, -1, 0, NULL, NULL),
+    BUILTIN("compadd", 0, bin_compadd, 0, -1, 0, NULL, NULL),
+    BUILTIN("compcall", 0, bin_compcall, 0, 0, 0, "TD", NULL),
 };
 
 static struct conddef cotab[] = {
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Jan 26 14:24:23 1999
+++ Src/Zle/zle_tricky.c	Wed Jan 27 12:55:02 1999
@@ -3172,6 +3172,105 @@
     } LASTALLOC;
 }
 
+/* This calls the given function for new style completion. */
+
+/**/
+static void
+callcompfunc(char *s, char *fn)
+{
+    List list;
+    int lv = lastval;
+    
+    if ((list = getshfunc(fn)) != &dummy_list) {
+	LinkList args = newlinklist();
+	char **p, *tmp;
+	int aadd = 0, usea = 1, icf = incompfunc;
+	
+	addlinknode(args, fn);
+	
+	zsfree(compcontext);
+	zsfree(compcommand);
+	compcommand = "";
+	if (inwhat == IN_MATH) {
+	    if (insubscr) {
+		compcontext = "subscript";
+		compcommand = varname ? varname : "";
+	    } else
+		compcontext = "math";
+	    usea = 0;
+	} else if (lincmd)
+	    compcontext = (insubscr ? "subscript" : "command");
+	else if (linredir) {
+	    compcontext = "redirect";
+	    if (rdstr)
+		compcommand = rdstr;
+	} else
+	    switch (inwhat) {
+	    case IN_ENV:
+		compcontext = "value";
+		compcommand = varname;
+		usea = 0;
+		break;
+	    case IN_COND:
+		compcontext = "condition";
+		break;
+	    default:
+		if (cmdstr) {
+		    compcontext = "argument";
+		    compcommand = cmdstr;
+		} else {
+		    compcontext = "value";
+		    if (clwords[0])
+			compcommand = clwords[0];
+		}
+		aadd = 1;
+	    }
+	compcontext = ztrdup(compcontext);
+	tmp = quotename(compcommand, NULL, NULL, NULL);
+	untokenize(tmp);
+	compcommand = ztrdup(tmp);
+	if (usea && (!aadd || clwords[0]))
+	    for (p = clwords + aadd; *p; p++) {
+		tmp = dupstring(*p);
+		untokenize(tmp);
+		addlinknode(args, tmp);
+	    }
+	zsfree(compprefix);
+	zsfree(compsuffix);
+	if (unset(COMPLETEINWORD)) {
+	    tmp = quotename(s, NULL, NULL, NULL);
+	    untokenize(tmp);
+	    compprefix = ztrdup(tmp);
+	    compsuffix = ztrdup("");
+	} else {
+	    char *ss = s + offs, sav;
+	    
+	    tmp = quotename(s, &ss, NULL, NULL);
+	    sav = *ss;
+	    *ss = '\0';
+	    untokenize(tmp);
+	    compprefix = ztrdup(tmp);
+	    *ss = sav;
+	    untokenize(ss);
+	    compsuffix = ztrdup(ss);
+	}
+	zsfree(compiprefix);
+	compiprefix = ztrdup("");
+	compcurrent = (usea ? (clwpos + 1 - aadd) : 1);
+	compnmatches = mnum;
+	incompfunc = 1;
+	startparamscope();
+	makecompparamsptr();
+	NEWHEAPS(compheap) {
+	    doshfunc(fn, list, args, 0, 1);
+	} OLDHEAPS;
+	endparamscope();
+	lastcmd = 0;
+	incompfunc = icf;
+    }
+    lastval = lv;
+}
+
 /* The beginning and end of a word range to be used by -l. */
 
 static int brange, erange;
@@ -3224,100 +3323,10 @@
 	ccused = newlinklist();
 	ccstack = newlinklist();
 
-	if (compfunc) {
-	    List list;
-	    int lv = lastval;
-
-	    if ((list = getshfunc(compfunc)) != &dummy_list) {
-		LinkList args = newlinklist();
-		char **p, *tmp;
-		int aadd = 0, usea = 1;
-
-		addlinknode(args, compfunc);
-
-		zsfree(compcontext);
-		zsfree(compcommand);
-		compcommand = "";
-		if (inwhat == IN_MATH) {
-		    if (insubscr) {
-			compcontext = "subscript";
-			compcommand = varname ? varname : "";
-		    } else
-			compcontext = "math";
-		    usea = 0;
-		} else if (lincmd)
-		    compcontext = (insubscr ? "subscript" : "command");
-		else if (linredir) {
-		    compcontext = "redirect";
-		    if (rdstr)
-			compcommand = rdstr;
-		} else
-		    switch (inwhat) {
-		    case IN_ENV:
-			compcontext = "value";
-			compcommand = varname;
-			usea = 0;
-			break;
-		    case IN_COND:
-			compcontext = "condition";
-			break;
-		    default:
-			if (cmdstr) {
-			    compcontext = "argument";
-			    compcommand = cmdstr;
-			} else {
-			    compcontext = "value";
-			    if (clwords[0])
-				compcommand = clwords[0];
-			}
-			aadd = 1;
-		    }
-		compcontext = ztrdup(compcontext);
-		tmp = quotename(compcommand, NULL, NULL, NULL);
-		untokenize(tmp);
-		compcommand = ztrdup(tmp);
-		if (usea && (!aadd || clwords[0]))
-		    for (p = clwords + aadd; *p; p++) {
-			tmp = dupstring(*p);
-			untokenize(tmp);
-			addlinknode(args, tmp);
-		    }
-		zsfree(compprefix);
-		zsfree(compsuffix);
-		if (unset(COMPLETEINWORD)) {
-		    tmp = quotename(s, NULL, NULL, NULL);
-		    untokenize(tmp);
-		    compprefix = ztrdup(tmp);
-		    compsuffix = ztrdup("");
-		} else {
-		    char *ss = s + offs, sav;
-
-		    tmp = quotename(s, &ss, NULL, NULL);
-		    sav = *ss;
-		    *ss = '\0';
-		    untokenize(tmp);
-		    compprefix = ztrdup(tmp);
-		    *ss = sav;
-		    untokenize(ss);
-		    compsuffix = ztrdup(ss);
-		}
-		zsfree(compiprefix);
-		compiprefix = ztrdup("");
-		compcurrent = (usea ? (clwpos + 1 - aadd) : 1);
-		compnmatches = mnum;
-		incompfunc = 1;
-		startparamscope();
-		makecompparamsptr();
-		NEWHEAPS(compheap) {
-		    doshfunc(compfunc, list, args, 0, 1);
-		} OLDHEAPS;
-		endparamscope();
-		lastcmd = 9;
-		incompfunc = 0;
-	    }
-	    lastval = lv;
-	} else
-	    makecomplistglobal(s, incmd, lst);
+	if (compfunc)
+	    callcompfunc(s, compfunc);
+	else
+	    makecomplistglobal(s, incmd, lst, 0);
 
 	endcmgroup(NULL);
 
@@ -3362,11 +3371,11 @@
 	if (*p == '\\')
 	    bslash = 1;
 	else {
-	    if (*p == '$') {
+	    if (*p == '$' || *p == '=') {
 		if (bslash)
 		    p[-1] = Bnull;
 		else
-		    *p = String;
+		    *p = (*p == '$' ? String : Equals);
 	    }
 	    bslash = 0;
 	}
@@ -3425,16 +3434,59 @@
     } SWITCHBACKHEAPS;
 }
 
+/**/
+void
+makecomplistctl(int flags)
+{
+    SWITCHHEAPS(compheap) {
+	HEAPALLOC {
+	    int ooffs = offs, lip, lp;
+	    char *str = comp_str(&lip, &lp), *t;
+	    char *os = cmdstr, **ow = clwords, **p, **q;
+	    int on = clwnum, op = clwpos;
+
+	    clwnum = arrlen(pparams) + 1;
+	    clwpos = compcurrent - 1;
+	    cmdstr = ztrdup(compcommand);
+	    clwords = (char **) zalloc((clwnum + 1) * sizeof(char *));
+	    clwords[0] = ztrdup(cmdstr);
+	    for (p = pparams, q = clwords + 1; *p; p++, q++) {
+		t = dupstring(*p);
+		ctokenize(t);
+		remnulargs(t);
+		*q = ztrdup(t);
+	    }
+	    *q = NULL;
+	    offs = lip + lp;
+	    incompfunc = 2;
+	    makecomplistglobal(str,
+			       (!clwpos && !strcmp(compcontext, "command")),
+			       COMP_COMPLETE, flags);
+	    incompfunc = 1;
+	    offs = ooffs;
+	    compnmatches = mnum;
+	    zsfree(cmdstr);
+	    freearray(clwords);
+	    cmdstr = os;
+	    clwords = ow;
+	    clwnum = on;
+	    clwpos = op;
+	} LASTALLOC;
+    } SWITCHBACKHEAPS;
+}
+
 /* This function gets the compctls for the given command line and *
  * adds all completions for them. */
 
 /**/
 static void
-makecomplistglobal(char *os, int incmd, int lst)
+makecomplistglobal(char *os, int incmd, int lst, int flags)
 {
     Compctl cc;
     char *s;
 
+    ccont = CC_CCCONT;
+
     if (lst == COMP_WIDGET) {
 	cc = compwidget->u.cc;
     } else if (inwhat == IN_ENV)
@@ -3463,16 +3515,17 @@
 	cc = &cc_default;
     else {
 	/* Otherwise get the matches for the command. */
-	makecomplistcmd(os, incmd);
+	makecomplistcmd(os, incmd, flags);
 	cc = NULL;
     }
     if (cc) {
 	/* First, use the -T compctl. */
-	makecomplistcc(&cc_first, os, incmd);
-
-	if (!(ccont & CC_CCCONT))
-	    return;
+	if (!(flags & CFN_FIRST)) {
+	    makecomplistcc(&cc_first, os, incmd);
 
+	    if (!(ccont & CC_CCCONT))
+		return;
+	}
 	makecomplistcc(cc, os, incmd);
     }
 }
@@ -3481,18 +3534,19 @@
 
 /**/
 static void
-makecomplistcmd(char *os, int incmd)
+makecomplistcmd(char *os, int incmd, int flags)
 {
     Compctl cc;
     Compctlp ccp;
     char *s;
 
     /* First, use the -T compctl. */
-    makecomplistcc(&cc_first, os, incmd);
-
-    if (!(ccont & CC_CCCONT))
-	return;
+    if (!(flags & CFN_FIRST)) {
+	makecomplistcc(&cc_first, os, incmd);
 
+	if (!(ccont & CC_CCCONT))
+	    return;
+    }
     /* Then search the pattern compctls, with the command name and the *
      * full pathname of the command. */
     makecomplistpc(os, incmd);
@@ -3520,9 +3574,11 @@
 	    (cc = ccp->cc)) ||
 	   ((s = dupstring(cmdstr)) && remlpaths(&s) &&
 	    (ccp = (Compctlp) compctltab->getnode(compctltab, s)) &&
-	    (cc = ccp->cc)))))
+	    (cc = ccp->cc))))) {
+	if (flags & CFN_DEFAULT)
+	    return;
 	cc = &cc_default;
-
+    }
     makecomplistcc(cc, os, incmd);
 }
 
@@ -3811,12 +3867,12 @@
 
     ccont |= (cc->mask2 & (CC_CCCONT | CC_DEFCONT | CC_PATCONT));
 
-    if (!incompfunc && findnode(ccstack, cc))
+    if (incompfunc != 1 && findnode(ccstack, cc))
 	return;
 
     addlinknode(ccstack, cc);
 
-    if (!incompfunc && allccs) {
+    if (incompfunc != 1 && allccs) {
 	if (findnode(allccs, cc)) {
 	    uremnode(ccstack, firstnode(ccstack));
 	    return;
@@ -4424,45 +4480,50 @@
 	/* Add user names. */
 	maketildelist();
     if (cc->func) {
-	/* This handles the compctl -K flag. */
-	List list;
-	char **r;
-	int lv = lastval;
-
-	/* Get the function. */
-	if ((list = getshfunc(cc->func)) != &dummy_list) {
-	    /* We have it, so build a argument list. */
-	    LinkList args = newlinklist();
-	    int osc = sfcontext;
-
-	    addlinknode(args, cc->func);
-
-	    if (delit) {
-		p = dupstrpfx(os, ooffs);
-		untokenize(p);
-		addlinknode(args, p);
-		p = dupstring(os + ooffs);
-		untokenize(p);
-		addlinknode(args, p);
-	    } else {
-		addlinknode(args, lpre);
-		addlinknode(args, lsuf);
+	if (cc->func[0] == ' ')
+	    /* Temporary hack for access to new style completione. */
+	    callcompfunc(os, cc->func + 1);
+	else {
+	    /* This handles the compctl -K flag. */
+	    List list;
+	    char **r;
+	    int lv = lastval;
+	    
+	    /* Get the function. */
+	    if ((list = getshfunc(cc->func)) != &dummy_list) {
+		/* We have it, so build a argument list. */
+		LinkList args = newlinklist();
+		int osc = sfcontext;
+		
+		addlinknode(args, cc->func);
+		
+		if (delit) {
+		    p = dupstrpfx(os, ooffs);
+		    untokenize(p);
+		    addlinknode(args, p);
+		    p = dupstring(os + ooffs);
+		    untokenize(p);
+		    addlinknode(args, p);
+		} else {
+		    addlinknode(args, lpre);
+		    addlinknode(args, lsuf);
+		}
+		
+		/* This flag allows us to use read -l and -c. */
+		if (incompfunc != 1)
+		    incompctlfunc = 1;
+		sfcontext = SFC_COMPLETE;
+		/* Call the function. */
+		doshfunc(cc->func, list, args, 0, 1);
+		sfcontext = osc;
+		incompctlfunc = 0;
+		/* And get the result from the reply parameter. */
+		if ((r = get_user_var("reply")))
+		    while (*r)
+			addmatch(*r++, NULL);
 	    }
-
-	    /* This flag allows us to use read -l and -c. */
-	    if (!incompfunc)
-		incompctlfunc = 1;
-	    sfcontext = SFC_COMPLETE;
-	    /* Call the function. */
-	    doshfunc(cc->func, list, args, 0, 1);
-	    sfcontext = osc;
-	    incompctlfunc = 0;
-	    /* And get the result from the reply parameter. */
-	    if ((r = get_user_var("reply")))
-		while (*r)
-		    addmatch(*r++, NULL);
+	    lastval = lv;
 	}
-	lastval = lv;
     }
     if (cc->mask & (CC_JOBS | CC_RUNNING | CC_STOPPED)) {
 	/* Get job names. */
@@ -4619,7 +4680,7 @@
 	    }
 
 	    /* No harm in allowing read -l and -c here, too */
-	    if (!incompfunc)
+	    if (incompfunc != 1)
 		incompctlfunc = 1;
 	    sfcontext = SFC_COMPLETE;
 	    doshfunc(cc->ylist, list, args, 0, 1);
@@ -4686,7 +4747,7 @@
 	    clwords += brange;
 	}
 	/* Produce the matches. */
-	makecomplistcmd(s, incmd);
+	makecomplistcmd(s, incmd, CFN_FIRST);
 
 	/* And restore the things we changed. */
 	clwords = ow;
--- om/new-completion-examples	Tue Jan 26 16:48:34 1999
+++ Misc/new-completion-examples	Wed Jan 27 12:36:17 1999
@@ -90,11 +90,20 @@
 # arguments from the command line are gives as positional parameters.
 
 main-complete() {
-  emulate -R zsh
+  # emulate -R zsh
   local comp
 
   setopt localoptions nullglob rcexpandparam globdots
   unsetopt markdirs globsubst shwordsplit nounset
+
+  # We first try the `compctl's. This is without first (-T) and default (-D)
+  # completion. If you want them add `-T' and/or `-D' to this command.
+  # If this produces any matches, we don't try new style completion. If you
+  # want to have that tried anyway, remove the `[[ -nmatches ... ]] ...'
+  # below.
+
+  compcall
+  [[ -nmatches 0 ]] || return
 
   # An entry for `--first--' is the replacement for `compctl -T'
   # The `|| return 1' is used throughout: if a function producing matches

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

RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> ...
> 
> What I think about, is two interfaces: compctl->new completion and new
> completion->compctl.

Until now I was only thinking about using `compctl's from completion
function (but in the same way you did). But I think we should give it
some arguments, e.g.: should `-T' be used, should `-D' be used, etc.

Hm... [time passes, thinking], no currently this doesn't look too hard 
to implement, but when dealing with the completion code you'll never
know ;-)


Bye
 Sven


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

RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Andrej Borsenkow]

>
> I haven't got around to considering the new completion in detail, but
> it did occur to me it could be better integrated with the widget
> completion I added, i.e. zle -c and zle -C could be made more similar.


Actually, after looking at new completion examples, I really think, all
three current ways to do completion should be merged.

compctl is suitable and enough in probably 90% of all cases - and with
post-3.1.5 additions even more (am I wrong?) And if you are lucky to have
the case from remaining 10%, the cool new completion stuff is excellent tool
to extend compctl.

What I think about, is two interfaces: compctl->new completion and new
completion->compctl. That is

compctl->new completion

  we need a way to call completion functions with environment set up
  as expected by new functions. Unfortunately, it is incompatible with
  current -K usage (as we need setup different args); do we have any
  character else free? :-) O.K., let's assume for now that it is 'K'

new completion->compctl

  there is already complist, that can be used to specify completion
  directly. Now, what is needed, is the way to tell: "use completion,
  defined for this command by compctl, if available". It is much the way,
  zle -C works already. Let's call it compcall :-)

  The way, in which compctl is called, must use the same convention
  (arg list and variables) as new completion. This will provide for nice
  recursive calls.

Consider two examples:

compctl -T -K __redirect_handler
function __redirect_handler () {
    case $CONTEXT in
        redirect )
            do completion of redirections
        ;;
    esac
}

This gives easy way to enable completion after redirection without actually
messing up all traditional compctl stuff. Yes, for those who already use -T,
it means some additional work ... But it only one function in this case :-)

Another one is small rewrite of new completion example:

compctl -K __precmd noglob nocorrect exec command builtin
__precmd() {
  COMMAND="$1"
  shift
  (( CURRENT-- ))
  if [[ CURRENT -eq 0 ]] then
    CONTEXT=command
  else
    CONTEXT=argument
  fi
  compcall -c "$1" # -- this calls compctl completion, defined for "$1"
                   # -- now compctl "sees" only modified arguments,
                   # -- that will be passed to any functions called
}

I actually feel very uneasy about replacing compctl interface with new
stuff. But it is really a pity to not use it.

Is it hard to implement? This will give you full flexibility of all three
ways to do completion and free choice, which one to use.

/andrej

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Peter Stephenson]

Sven Wischnowsky wrote:
> > I would like to start play with new completion stuff. But I do not want to
> > completely lose all current compctl's I have.
> 
> No, currently I'm not sure how to do this.

I wondered about this, too, and while I'm spending most of my time
replying to zsh-workers mail...

I haven't got around to considering the new completion in detail, but
it did occur to me it could be better integrated with the widget
completion I added, i.e. zle -c and zle -C could be made more similar.
Then you should be able to use arbitrary old-style compctls from any
zle function.  One way of doing this is using compctl -L to get the
old definition, dumping that straight into a widget with zle -C, and
calling that --- I think that can even be done now with a bit of sed
or equivalent, although -C doesn't handle different completion
functions as well as -c does, which is the main user-visible change
I'd like to make.

However, it might be better to allow a modified zle -C which copies
the widget from an existing compctl --- maybe it should even call it
straight away and delete it, i.e. then you get what Andrej is asking
for in one go.  Internally, I don't think that's too hard.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> 
> I would like to start play with new completion stuff. But I do not want to
> completely lose all current compctl's I have. What I would really like, is
> something like
> 
>   if defined new style completion
>      do it
>   else
>      use compctl completion
> 
> Is it possible?

I knew someone would ask for this...

No, currently I'm not sure how to do this. Providing a builtin
(`compold' or whatever) to generate the completions from a compctl
shouldn't be too hard. But if you have a definition for default
completion  in the new style stuff you probably want to use compctl's
only if there is one for the command (not -T, -D, ...). On the other
hand some people may want them to be used, or only sometimes, or...

Maybe we should instead provide a function that automatically converts
compctls into definitions for the new completion stuff. Transforming
them by hand as I did at the weekend is very tedious anyway.
But then again, the things in `new-completion-examples' are only
examples. One advantage of the new style is that you can almost
completely define the way completion is done by implementing your own
functions. So we could only write a function to convert to the style
used currently in `new-completion-examples', there is no way to write
a generic function for this. Also, the example stuff still isn't
complete, for example I currently use function return values as a
replacement for `-t', but not all functions do this correctly or
handle those return values.

But for those who only want to play with it: you can probably bind the 
new completion to a different key, keeping TAB for the compctl-stuff,
by changing the bindkey-argument in `new-completion-examples'.

Bye
 Sven

P.S.: Sorry.

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

zsh-3.1.5-pws-5: mixing "old" and "new" completions?

[Andrej Borsenkow]

I would like to start play with new completion stuff. But I do not want to
completely lose all current compctl's I have. What I would really like, is
something like

  if defined new style completion
     do it
  else
     use compctl completion

Is it possible?

TIA

/andrej