completion behaviour (was: zsh-workers: zsh-3.1.5 released)

completion behaviour (was: zsh-workers: zsh-3.1.5 released)

[Sven Wischnowsky]

Zefram wrote:

> 
> Sven: would you please update your completion patches, and post
> new versions based on vanilla 3.1.5.  Specifically, the patches for
> inclusive ORing, grouping of completions, and the configurable fuzziness
> of matching.  I like all of these features.
> 

Before I start incorporating these things into 3.1.5 I'd like to ask a
few questions.

We had some discusssion about a new way to define completion behaviour 
which (seemingly) settled on: let's use shell functions and offer a
few new builtins. So, if I implement this, do we really want the
changes to compctl (note: I mean compctl, most of the changes in the
completion code itself would be used anyway) or should we leave
compctl alone and offer the new possibilities through the new way to
define completion behaviour, thereby giving some incentive to switch
to the new way?

Anyway, here is my suggestion for this new completion definition
stuff:


We use zle widgets, probably a new kind of widgets that uses some more 
special variables, like:

  CMDSTR   - the name of the current command, with some special values
             it could be used for certain contexts (conditions, math
             expressions, ...)
  words    - the words of the current command (an array)
  CURWORD  - the number of the current word (for words[CURWORD])
  PREFIX   - the prefix of the current word
  SUFFIX   - ...
  NMATCHES - the number of matches produced so far

Of course, many more interesting things can be thought of.

Using a special widget for this ensures that we have a common wrapper
function in the C code that must be used. The new builtins can be
called only from  such a widget or functions called from it and in the 
C code this should make it possible to leave most of the completion
code unchanged (especially the allocation behaviour).

The general procedure would be to define such a completion widget that
serves as a kind of main loop, calls other functions to produce the
matches and finally decides what to do with the matches (listing,
inserting, ...)

To make the definition and calling of completion functions for certain
commands easier there could be a new builtin, say `compfunc':

  compfunc -a <func-name> <cmd-names-or-patterns ...>

    Makes <func-name> be called for the given command. <func-name> may 
    be one of a few special strings for replacing `compctl -C -T -D'.

  compfunc -d <cmd-names-or-patterns ...>

    Deletes definitions.

  compfunc -c [ <cmd-str> ]

    Makes all of the defined functions for $CMDSTR or the given
    <cmd-str> be called (this is most of the main loop of the current
    completion code). We could use the return code of the completion
    functions to decide whether more functions should be called or
    not.

  compfunc [ -L ]

    Lists the definitions, probably in a form that could be used in
    .zshrc or wherever.

For producing the actual matches there is another builtin, say
`compadd'. For simplicity we could make it use the same flags
`compctl' uses now, but without `-x', `+', and the like, i.e. only the 
simple match-producing flags. This would allow us to re-use most of
the code for compctl and since only the simple flags would be
supported, the irritating part of compctl would not be inherited.

On the other side we might wih to clean things up and make `compadd'
get new options for the things to produce. This could also be combined 
with a different way to handle control flags (-U, -q,
grouping,...). We could make these flags be used `from now on' and
probably have a way to save/restore the current set of control flags
(whose state would be stored together with the matches produced),
e.g. (in an easy-to-read syntax):

  compadd -push
  compadd -quote -suffix '/'
  compadd -files               # optional glob pattern here
  ...
  compadd -pop

I'm not quite sure which would be better. But of course it should be
possible to write some helper functions that offer one of the syntaxes 
and internally uses the other.

Probably the most important change would be how xor'ed completion,
extended completion, and the like are handled - using shell
constructs.

Xor'ed completion is simple if we have the special variables mentioned 
above (or some way to get this information from the completion code):

  old=$NMATCHES
  compadd ...                        # try to produce some matches
  ...
  if [[ $old -eq $NMATCHES ]] then   # this is the xor test
    compadd ...
    ...
  fi
                                     # more xor tests could be here

More interesting is the replacement for `compctl -x'. As Bart already
pointed out, we could use things like:

  if [[ "$words[CURWORD-1]" = "-I" ]] then
    compadd -W /usr/include -/
  fi

I.e. use the normal shell tests and the special variables. But there
is a problem with this: with compctl the `-x' - tests not only test
for a certain condition, but also report some information back,
namely: the length of an prefix that should be ignored in the
completion string and (with `r[a,b]') a restriction on the command
words that should be used with `compctl -L'. Both of them are
important to have and aren't that easy to do by hand, so we might want 
to add a builtin for testing, say `comptest' that has options for the
different tests and automatically makes the completion code use the
resulting restrictions. Since these restrictions should be used only
for some `compadd's, we would also need a way to switch back to the
original (or previous) state, e.g.:

  if comptest -suffix '-'; then      # makes `-' be ignored
    compadd ...
    ...
    comptest -fin                    # old state again
  fi

Alternatively we could have a option meaning: activate the
restrictions resulting from the last test.

Finally we would need a way to insert the matches or the unambiguous
string for normal completion in the line. Since we are in a zle widget 
we could just add a way to get the prefix/suffix to insert from the
completion code and than fiddle with [LR]BUFFER (there is a problem
with automatically removable suffixes).

So we might add a builtin to control all this, e.g.:

  complist -i [ <number> ]

    The first effect of this is that the completion code calculates
    the things the user might want to insert. Without argument this
    inserts the unambiguous string, with argument it inserts the
    <number>'th match (this is needed to implement the menu-completion
    behaviour).

  complist -k

    This notifies the completion code that the list of matches is to
    be kept so that the next invocation of the completion widget can
    test if there is still a valid list of matches and then continue
    menu-completion.

  complist -c

    This is the counterpart of `-k'. If the completion widget still
    has a a valid list but the completion string has changed we need
    to clear the list so that we can produce the matches for the new
    string.

`complist' should also offer ways to access some more information,
especially we need a way to decide if the recexact and listambiguous
behaviour should be emulated.

Finally we need a way to make the completion code list the matches
found. This could be done with `complist' or by using the return code
of the completion widget.

Some final remarks:

- Using special variables isn't necessary, we could offer a way to
  make the information be stored in some variables with use-supplied
  names (and partially we already have this, of course).
- The new builtins may have different names and options. Also I'd like 
  to think about combining soome of the builtins.
- The matching control could be improved, too (not only the syntax ;-). 
  We might have a builtin/optio to some builtin for defining sets of
  matching controls under a user-supplied name and a flag to `compadd' 
  that uses these names.
- Using shell functions may also be a first step in supporting
  higher-level descriptions, e.g.:

    function opt-arg() {
      [[ "$words[CURWORD-1]" = "$1" ]] && compadd "$argv[2,-1]"
    }

  With that we could make paths in `/usr/include' after `-I' be
  completed with: 

    opt-arg -I -W /usr/include -/


So, now I would like to read some comments about all this ;-)

Bye
 Sven


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

Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)

[Peter Stephenson]

Sven Wischnowsky wrote:
> We had some discusssion about a new way to define completion behaviour 
> which (seemingly) settled on: let's use shell functions and offer a
> few new builtins. So, if I implement this, do we really want the
> changes to compctl (note: I mean compctl, most of the changes in the
> completion code itself would be used anyway) or should we leave
> compctl alone and offer the new possibilities through the new way to
> define completion behaviour, thereby giving some incentive to switch
> to the new way?

It's hard enough having to keep track of compctl changes without
having to think about doing everything a completely different way.
I'd much prefer everything to be reachable from compctl for the time
being.  I realise it's not necessarily going to look nice, but that
has never really been compctl's aim.

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

Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)

[Zefram]

Sven Wischnowsky wrote:
>We had some discusssion about a new way to define completion behaviour 
>which (seemingly) settled on: let's use shell functions and offer a
>few new builtins. So, if I implement this, do we really want the
>changes to compctl (note: I mean compctl, most of the changes in the
>completion code itself would be used anyway) or should we leave
>compctl alone and offer the new possibilities through the new way to
>define completion behaviour, thereby giving some incentive to switch
>to the new way?

I wondered about this myself, but came to the conclusion that new
completion features should be made available via compctl until the new
interface has been implemented.  After the new interface is in place we
can freeze compctl.

>We use zle widgets, probably a new kind of widgets that uses some more 
>special variables, like:

We can have a single widget that acts as the main interface to completion,
creating these variables and calling user-defined widgets to do the
real work.

>To make the definition and calling of completion functions for certain
>commands easier there could be a new builtin, say `compfunc':

I'm not convinced by this.  I'd rather get associative arrays working,
and use a non-special array to store this information.  I'd like the user
to be able to totally redefine the way that completions are associated
with command names.

>For producing the actual matches there is another builtin, say
>`compadd'. For simplicity we could make it use the same flags
>`compctl' uses now, but without `-x', `+', and the like, i.e. only the 
>simple match-producing flags. This would allow us to re-use most of
>the code for compctl and since only the simple flags would be
>supported, the irritating part of compctl would not be inherited.

Yes, this is good.  I was wondering how to make the match structures
user accessible.  Using the compctl-style interface to build up a
specially-handled list of matches solves this, and gives the user access
to the full power of the completion system.

OTOH, I think this perhaps should be split into two builtins.  One to
add sets of matches in a manner based on the compctl syntax (this could
even be part of the compctl module, and use the compctl code to handle
*all* the compctl options).  Another, more basic builtin would merely
provide an interface for adding a single match (or a set of matches),
with options to separately control each part of the match structure.

>is a problem with this: with compctl the `-x' - tests not only test
>for a certain condition, but also report some information back,
>namely: the length of an prefix that should be ignored in the
>completion string

This should be part of the match structure, and the user should be able
to control it explicitly.

-zefram

Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)

[Sven Wischnowsky]

Zefram wrote:

> 
> Sven Wischnowsky wrote:
> >We had some discusssion about a new way to define completion behaviour 
> >which (seemingly) settled on: let's use shell functions and offer a
> >few new builtins. So, if I implement this, do we really want the
> >changes to compctl (note: I mean compctl, most of the changes in the
> >completion code itself would be used anyway) or should we leave
> >compctl alone and offer the new possibilities through the new way to
> >define completion behaviour, thereby giving some incentive to switch
> >to the new way?
> 
> I wondered about this myself, but came to the conclusion that new
> completion features should be made available via compctl until the new
> interface has been implemented.  After the new interface is in place we
> can freeze compctl.
> 

There seems to be more support for good ol' compctl than I expected ;-)

> >We use zle widgets, probably a new kind of widgets that uses some more 
> >special variables, like:
> 
> We can have a single widget that acts as the main interface to completion,
> creating these variables and calling user-defined widgets to do the
> real work.
> 

I meant that even the main completion widget is a user defined one and 
calls shell functions to do the real work.

> >To make the definition and calling of completion functions for certain
> >commands easier there could be a new builtin, say `compfunc':
> 
> I'm not convinced by this.  I'd rather get associative arrays working,
> and use a non-special array to store this information.  I'd like the user
> to be able to totally redefine the way that completions are associated
> with command names.
> 

Interesting. I was thinking a lot about associative arrays when
thinking about this completion definition stuff. I just didn't dare to 
suggest implementing them (and we would really need them if we have
this completion thing).
So, if we are expecting to implement associative arrays with some
really powerful mechanisms (think about the pattern matching stuff
completion will/should support), I'm all for avoiding the compfunc stuff.

> >For producing the actual matches there is another builtin, say
> >`compadd'. For simplicity we could make it use the same flags
> >`compctl' uses now, but without `-x', `+', and the like, i.e. only the 
> >simple match-producing flags. This would allow us to re-use most of
> >the code for compctl and since only the simple flags would be
> >supported, the irritating part of compctl would not be inherited.
> 
> Yes, this is good.  I was wondering how to make the match structures
> user accessible.  Using the compctl-style interface to build up a
> specially-handled list of matches solves this, and gives the user access
> to the full power of the completion system.
> 
> OTOH, I think this perhaps should be split into two builtins.  One to
> add sets of matches in a manner based on the compctl syntax (this could
> even be part of the compctl module, and use the compctl code to handle
> *all* the compctl options).  Another, more basic builtin would merely
> provide an interface for adding a single match (or a set of matches),
> with options to separately control each part of the match structure.
> 

Another one of the ideas I had, too. Yes, it would be nice to give the 
user full control about the things stored for each match (this was
part of the reason I suggested compadd with differnet options). The
old style is still interesting to have since it is much easier to use
(we store quite a bit of information with the matches).

> >is a problem with this: with compctl the `-x' - tests not only test
> >for a certain condition, but also report some information back,
> >namely: the length of an prefix that should be ignored in the
> >completion string
> 
> This should be part of the match structure, and the user should be able
> to control it explicitly.
> 

Partly agreed (see above), but I would still like to give the user
some more support. Think of `r[-exec,;]'. The user would have to do the
matching and before (s)he can produce matches (s)he would have to tell
the completion code which command words should not be used. This can
get a bit nasty.


Bye
 Sven


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

Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)

[Zefram]

Sven Wischnowsky wrote:
>So, if we are expecting to implement associative arrays with some
>really powerful mechanisms (think about the pattern matching stuff
>completion will/should support),

*double take*

Hmm, I didn't consider the pattern matching aspect when I suggested using
associative arrays.  But since the existing hashtable code provides an
interface for pattern matching lookups, it shouldn't be difficult to
provide a user interface.

>Partly agreed (see above), but I would still like to give the user
>some more support. Think of `r[-exec,;]'. The user would have to do the
>matching and before (s)he can produce matches (s)he would have to tell
>the completion code which command words should not be used. This can
>get a bit nasty.

What you need there is for the user-defined completion function, after
recognising the "-exec", to recursively invoke the completion mechanism
on the restricted range of words.  As long as completion can be invoked
recursively, there's no need for more specific support for this type
of construct.  (Consider also how to properly handle completion of the
word after "sh -c".)

-zefram

Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)

[Sven Wischnowsky]

Zefram wrote:

> ...
> 
> >Partly agreed (see above), but I would still like to give the user
> >some more support. Think of `r[-exec,;]'. The user would have to do the
> >matching and before (s)he can produce matches (s)he would have to tell
> >the completion code which command words should not be used. This can
> >get a bit nasty.
> 
> What you need there is for the user-defined completion function, after
> recognising the "-exec", to recursively invoke the completion mechanism
> on the restricted range of words.  As long as completion can be invoked
> recursively, there's no need for more specific support for this type
> of construct.  (Consider also how to properly handle completion of the
> word after "sh -c".)
> 

Let's clear this once and for all. Currently the testing code produces 
two types of information: the length of an ignored prefix and a
possible range restriction in the command words. Without special
support, the user would have to do the test and then manually notify
the completion code of the restrictions to use (the prefix stuff for
almost all completions and the range restriction for `-l' which is
your example). In some cases this is trivial (e.g. for `S[-]'), in
some cases it is not that easy (e.g. `n[-1,/]' or `r[-exec,;]').
Personally I don't care if we would have to manually notify the
completion code, but I guess some users would like to have an easier
way. On the other hand, we could put examples for the most obvious
things in the manual.

Maybe I'll write an updated version of my suggestion in the next days.

Bye
 Sven


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

new completion behaviour version 2

[Sven Wischnowsky]

Ok, here is the update I promised...

We need some kind of C-wrapper function around the completion code, so 
we either have one new builtin widget that calls a shell function to
do the real work or we have a new type of user-defined-widgets which
do the work, probably calling other shell functions to produce the
matches.

Information about the context for producing the matches is normally
obtained in the top level shell function (or the new-type widget),
stored in local variables and thereby made accessible in called
functions, but of course users can implement this differently. Of the
information that is important to have the command words and the index
into this array are already available via `read'. The prefix and
suffix can be made accessible via `read', too, or as arguments when
calling the top level function (as with compctl-K-functions). Another
interesting information is the environment, i.e. `condition',
`redirection', and the like, which could be made accessible like the
prefix/suffix. To be able to implement things like xor'ed completion
in a shell function we need a way to access the number of matches
produced so far. This information differs from the other ones because
it changes whenever matches are added (of course). If we avoid special 
variables for all the other things we shouldn't add one for this, so
the users will have to call `read' repeatedly to get the current
number of matches.

Since most people will put their completion definitions in shell
functions, we need a way to at least map strings (command names) to
other strings (function names). This will be done either with
associative arrays or with the `$funcs[$cmds[(i)$CMDNAME]]'-trick. For 
command name patterns we can start using a simple array until we find
something more clever.

For producing matches we have a new builtin that uses the
compctl-flags (and part of it's code) to specify which matches should
be generated. Either this builtin or another new builtin will support
a way to directly set all the different things that are stored
together with the matches.

The coding scheme for xor'ed completion is trivial. The code for `-x'
stuff will be done using `if'-tests with the information stored in
local variables. We then need a way to notify the completion code
about two things it will have to use (to be able to do the same things 
`-x' can): the length of an ignored prefix of the current word and
(for `-L') which part of the words-array should be taken as command
words. Of course we should do this in a very general manner, giving
users the possibility to report restrictions `-x' doesn't use. To be
able to correctly save/restore this type of information we will need a 
way to get the current state in a way that can be used to restore it
later (so that independently developed completion functions can
restore the restrictions to the state they were in when the function
was called). All this could be done with the builtin that produces the 
matches (or the one that gives full control over the match structure
if we put this into a separate builtin).

Finally we need a way to put a match in the command line and to list
matches. Listing is simple (one way or the other). More interesting is 
putting matches on the line. I still find it tempting to think about
ways to use the special variables [LR]BUFFER for this. The only
problem with this are automagically removed suffixes (getting the
prefix/suffix from the completion code is simple nowadays). So if we
add a way to make removable suffixes completely user-controllable this 
may be the best solution (and giving the user full control over this
is interesting in itself, just think about the `compctl ... -S/ -q'
example from Bart). So we would end up with a builtin that allows one
to retrieve information about the matches (the prefix/suffix to
insert, and probably all the other things stored with the matches),
starting a new set of matches, listing them, and so on. With this
builtin we could also let users remove specific matches, change them,
etc. All this could later be added if we find uses that make them
desirable.

So, I hope this approach is simple enough. Comments?

Bye
 Sven


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

Re: new completion behaviour version 2

[Bart Schaefer]

I have some comments I'd like to make on this, but I've been quite busy the
last 24 hours and will continue to be until sometime this afternoon.  I'll
try to respond as soon as I can.

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

Re: new completion behaviour version 2

[Bart Schaefer]

Finally catching up on this part, too ... there's a bit of skipping
around in the following because I don't want to rehash things that
were already discussed, such as using an associative array instead of
a "compfunc" command.

On Nov 2, 11:36am, Sven Wischnowsky wrote:
} Subject: completion behaviour (was: zsh-workers: zsh-3.1.5 released)
}
} We use zle widgets, probably a new kind of widgets that uses some more 
} special variables, like:
} 
}   CMDSTR   - the name of the current command, with some special values
}              it could be used for certain contexts (conditions, math
}              expressions, ...)
}   words    - the words of the current command (an array)
}   CURWORD  - the number of the current word (for words[CURWORD])
}   PREFIX   - the prefix of the current word
}   SUFFIX   - ...
}   NMATCHES - the number of matches produced so far

If we're going to add associative arrays anyway (which I take it would
just be some kind of parameter syntax for frobbing a hash table) then
I'd just as soon have the set of scalars (CMDSTR, CURWORD, etc.) be in
such an associative array.

As for the words of the current command ... I'm thinking I'd like them
to come in as the positional parameters.  We already have syntax for
altering the $* array (shift, set, and 3=foo among other things); it
should be possible to recapture the contents after the function exits;
and it is an extremely intuitive way to refer to the command line.

(You can almost do this today by using
	read -Ac argv ; shift
in a compctl -K function, except that stomps the $1/$2 prefix/suffix.)

} For producing the actual matches there is another builtin, say
} `compadd'.  [...]
} with a different way to handle control flags (-U, -q,
} grouping,...). We could make these flags be used `from now on' and
} probably have a way to save/restore the current set of control flags
} (whose state would be stored together with the matches produced),
} e.g. (in an easy-to-read syntax):
} 
}   compadd -push
}   compadd -quote -suffix '/'
}   compadd -files               # optional glob pattern here
}   ...
}   compadd -pop

The main problem I have with this is that it's too easy to forget the
"pop".  If you want to do something of this sort, it really needs its
own syntax.  One way to accomplish that without having to muck about
with the zsh parser is to supply ONLY the "push" version of the command,
but define it to extend exactly to the end of the current function, as
for "local" variables and "setopt localoptions".  The user can control
scope by defining functions that call one another.
 
} I.e. use the normal shell tests and the special variables. But there
} is a problem with this: with compctl the `-x' - tests not only test
} for a certain condition, but also report some information back,
} namely: the length of an prefix that should be ignored in the
} completion string and (with `r[a,b]') a restriction on the command
} words that should be used with `compctl -L'.

Pardon my density, but I don't follow the connection between r[a,b] and
`compctl -L'.  Do you mean `compctl -l'?

}   complist -k
}   complist -c

Incidentally, with respect to menu completion, I don't think the widget
should get involved directly in cycling through the menu choices.  (I
can easily be convinced otherwise, but right now I don't see a compelling
argument.)  Once the the control flags have indicated that you have a
menu of choices, don't invoke the widget again until the prefix changes.
That is, the widget can say "here are the completions, and here is where
you insert them" but then let hardwired code take over cycling through
the menu if there are multiple matches.

} `complist' should also offer ways to access some more information,
} especially we need a way to decide if the recexact and listambiguous
} behaviour should be emulated.

Recexact can be emulated entirely by the wiget by simply producing only
a single match.  Listambiguous can be a flag attached to the generated
list of matches, can it not?

} Finally we need a way to make the completion code list the matches
} found. This could be done with `complist' or by using the return code
} of the completion widget.

I do think the return code should be meaningful, but only in a success/
failure sense like any other shell function; e.g. if the widget returns
nonzero and there are no other functions left to try, then feep).

On Nov 2, 11:29am, Zefram wrote:
} Subject: Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)
}
} >For producing the actual matches there is another builtin, say
} >`compadd'.
} 
} OTOH, I think this perhaps should be split into two builtins.  One to
} add sets of matches in a manner based on the compctl syntax (this could
} even be part of the compctl module, and use the compctl code to handle
} *all* the compctl options).  Another, more basic builtin would merely
} provide an interface for adding a single match (or a set of matches),
} with options to separately control each part of the match structure.

What I had in mind a while back was an interface to add one or more
matches with options for the controls associated with that collection
of matches; plus interfaces (possibly commands, possibly variables) to
obtain the information that's currently only available to compctl and
pass it to the add-matches interface.

So for example there would be a command or an array variable that gives
the names of all the disabled commands, and you'd do

	compadd $disabled

instead of

	compadd -dFB

(That's probably not the best example, but just to give the idea.)

} >is a problem with this: with compctl the `-x' - tests not only test
} >for a certain condition, but also report some information back,
} >namely: the length of an prefix that should be ignored in the
} >completion string
} 
} This should be part of the match structure, and the user should be able
} to control it explicitly.

I agree that the user should be able to control it, but it may be easier
for the completion code to compute a default.  Expose power you can use
if you want it, but don't require that you use it.

On Nov 2,  1:00pm, Sven Wischnowsky wrote:
} Subject: Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)
}
} Partly agreed (see above), but I would still like to give the user
} some more support. Think of `r[-exec,;]'. The user would have to do the
} matching and before (s)he can produce matches (s)he would have to tell
} the completion code which command words should not be used. This can
} get a bit nasty.

I agree, and I liked your comptest idea.  For example, something like

	if comptest index -1 / ; then

to mean what n[-1,/] accomplishes now.  (There could even be a flag in
[[ ]] to mean "test completions", e.g., [[ -C index -1 / ]] for the
above.)

The issue I see is with keeping the results sane should the user change
CURWORD (or whatever represents it).  But that's no more serious than
answering the question "where do I zle-insert this match if the widget
has repositioned the cursor?"

On Nov 2, 12:31pm, Zefram wrote:
} Subject: Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)
}
} What you need there is for the user-defined completion function, after
} recognising the "-exec", to recursively invoke the completion mechanism
} on the restricted range of words.  As long as completion can be invoked
} recursively, there's no need for more specific support for this type
} of construct.  (Consider also how to properly handle completion of the
} word after "sh -c".)

Recursively invoking completion functions is a good idea, and IMNSHO is
the best argument that I can think of for passing the command words as
the positional parameters.  (There is of course still the issue of $0,
but that's not too terrible.  Just assign to CMDSTR or whatever takes
its place in the associative array, before calling the other function.)

On Nov 3,  4:58pm, Sven Wischnowsky wrote:
} Subject: new completion behaviour version 2
}
} The coding scheme for xor'ed completion is trivial. The code for `-x'
} stuff will be done using `if'-tests with the information stored in
} local variables. We then need a way to notify the completion code
} about two things it will have to use (to be able to do the same things 
} `-x' can): the length of an ignored prefix of the current word and
} (for `-L') which part of the words-array should be taken as command
} words.

I still think you must mean `-l' there.  Un-confuse me, please.

} To be
} able to correctly save/restore this type of information we will need a 
} way to get the current state in a way that can be used to restore it
} later

Once again I suggest using function scope; save and restore like local
variables and setopts.

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