Re: PATCH: _expand, _expand_word, and their doc

Re: PATCH: _expand, _expand_word, and their doc

[Sven Wischnowsky]

As I said, I didn't find much time at the weekend, but I've been
playing and thinking a bit.

Bart Schaefer wrote:

> ...
> 
> Hm.  I don't have any overwhelming disagreement with that; the issue is
> not so much that _expand_word should handle it, as that _expand should
> not -- Andrej is clearly correct that _match is what actually does the
> most-correct thing in terms of generating the possible completions, so
> the question is how to get them all (offered to be) inserted at once.

As you said below, it isn't really _match either. It's any completer
that generates completions. And after re-thinking, I'm not so sure
about adding all completions as a single match anymore either. What
Andrej suggested (using an old list) really seems most useful for me
currently (getting a list, looking at it and then deciding to insert
them all -- less keystrokes than menuing to the all-completions entry).

(And the reason is not only that, trying a simple implementation, I
had some small problems getting it to work -- problems with the
prefix/suffic handling and when completing inside braces. That could
probably be solved.)

And the fact that _expand can offer both doesn't worry me very much
either, since there we are expanding a pattern the shell would expand
there anyway. It only looks slightly weird if one only things about
the combination of _match and inserting all completions.

> ...
> 
> I'd say we should use a new completer which has to appear very late in
> the completer list, and which modifies the handling of the completions
> that are generated before it is called.  As you suggest here:

I agree that this ordering looks sensible, but only unless one wants
it to re-use an old list. Then it should be at the very beginning,
which is almost an argument in favour of code like the one in
_expand. Or to put the whole thing into it's own completer that can
use an old list or builds a new one, calling the other completers
directly.

Hm, that would also be the easiest solution and could already be
implemented without having to change the C-code.


Bye
 Sven


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

Re: PATCH: _expand, _expand_word, and their doc

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Oct 5,  7:34pm, Andrej Borsenkow wrote:
> }
> } > What would you (or anyone else) think of removing insert-all-completions
> } > from _expand entirely (thus eliminating the -c option) and instead put
> } > compstate[insert]=all at the end of _expand_word (after _main_complete)?
> } 
> } What has inserting all *completions* to do with *expansions* (and thus
> } _expand_word)?
> 
> You're starting from an initial pattern and expanding it into a set of
> strings, aren't you?  What difference does it make whether the way you
> got those strings was by globbing, parameter substitution, history, or
> by invoking the completion system, or anything else?

Right. I have to admit, though, that I put it there mainly because we
were at that time using the word `expanding' for this multiple-matches
insertion.

Anyway. The reason why I don't really like the completions style to be 
handled there is that -- as Andrej mentioned once -- the matches are
generated different than the expansions. Not even by _expand itself
(which just looked like a clever trick at that time).

So, I would mainly vote for changing the way the completions are
generated, using the way we do it in _prefix and _ignore, only the
other way round. I.e. we look up the completer style in the new
context and use the global list if it isn't set there. From that list
we remove the `uninteresting' completers as Bart did in _e_w (_prefix
and _ignore should probably do the same). That way the whole thing
would be self-contained again.

Then we leave it either in _expand or put it into a separate
completer, depending on how strongly people feel that this is
different from what _expand does: the fact that we can offer
expansions in different ways -- in one string or separately -- should
be taken into account there, unless we make that possible for
completions, too. And I think it would be possible, probably by adding 
a new option to compadd which makes it add a string with all matches
generated so far (and then remove the `all' special value for
compstate[insert]). I'm not exactly sure about the implications (inter 
alia because I see two different ways to implement it), but I would be 
willing to give it a try. With that, it would almost make sense to add 
that feature to _complete itself, making it look (feature-wise) more
like _expand.

I don't, however, like to put it only into a bindable command, because 
then people can't configure it to get all completions with, say, a
numeric prefix and TAB. And just adding a bindable command that makes
all completions be inserted when we have a completer for it is simple
(or just documenting the trick with _generic).

So, does that thing with allowing completions added separately to be
offered together with a string with all completions sound too esoteric 
or do you really like it. And should we then put it into _complete? (I 
mean, the weekend is coming up, so I should have the time to try to
implement it... ;-)

Bye
 Sven


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

RE: PATCH: _expand, _expand_word, and their doc

[Andrej Borsenkow]

> >
> > You're starting from an initial pattern and expanding it into a set of
> > strings, aren't you?  What difference does it make whether the way you
> > got those strings was by globbing, parameter substitution, history, or
> > by invoking the completion system, or anything else?
>

Pragmatical answer: because currently we can select between individual
expansions or all expansions, but cannot do it with completions.

Metaphysical answer: I always considered expansion to be complementary to
completion. Completion is always context-sensitive (in the very broad sense
sometimes). We select from the fixed set of possible values; this set depends
on context but values itself do not depend on initial pattern. With expansion
we just evaluate the pattern; thus, the set of values does not depend on
context in any way, but values itself obviously depend on initial string.
Exactly the fact that completion is context-dependent action makes it possible
(in most cases) to group matches, to provide decriptions etc. All this is
inherently impossible with expansions, that do not have any internal structure
(the only sensible way to group them is by the way intial string is
evaluated - globbing, parameter expansion - that is done currently).

Mmm ... sorry, I have not expected it to be so long :-)

>
> Anyway. The reason why I don't really like the completions style to be
> handled there is that -- as Andrej mentioned once -- the matches are
> generated different than the expansions. Not even by _expand itself
> (which just looked like a clever trick at that time).
>

Excellent terse form of the above :-))

>
> I don't, however, like to put it only into a bindable command, because
> then people can't configure it to get all completions with, say, a
> numeric prefix and TAB. And just adding a bindable command that makes
> all completions be inserted when we have a completer for it is simple
> (or just documenting the trick with _generic).
>

Well, it is a matter of taste. I prefer to get a list first and then decide if
I want to insert it. It takes exactly the same amount of keystrokes; does it
make any difference between 'ESC-1-TAB' and 'TAB-^X-i'? Implementing this
needs a bit more than just wrapper around completer but does not need any
extra C-code at all (almost - issue with menu-selection remains).

Question to Sven - with noautolist, noautomenu - which value
compstate[old_list] has after the first TAB? Is list still generated and kept
internally even if it is not shown?

> So, does that thing with allowing completions added separately to be
> offered together with a string with all completions sound too esoteric
> or do you really like it. And should we then put it into _complete? (I
> mean, the weekend is coming up, so I should have the time to try to
> implement it... ;-)
>

I probably won't use it, but won't object, of course.

-andrej

RE: PATCH: _expand, _expand_word, and their doc

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> ...
>
> > I don't, however, like to put it only into a bindable command, because
> > then people can't configure it to get all completions with, say, a
> > numeric prefix and TAB. And just adding a bindable command that makes
> > all completions be inserted when we have a completer for it is simple
> > (or just documenting the trick with _generic).
> 
> Well, it is a matter of taste.

For me it's mostly a matter of allowing more ways to configure the thing.

> I prefer to get a list first and then decide if
> I want to insert it. It takes exactly the same amount of keystrokes; does it
> make any difference between 'ESC-1-TAB' and 'TAB-^X-i'? Implementing this
> needs a bit more than just wrapper around completer but does not need any
> extra C-code at all (almost - issue with menu-selection remains).

I forgot: that re-use old list striked me as sensible, too, so I agree 
that we should allow it somehow. Either with a style in the completer
itself, or, maybe, in _oldlist. With the old-list style set to `all'
or some such.

> Question to Sven - with noautolist, noautomenu - which value
> compstate[old_list] has after the first TAB? Is list still generated and kept
> internally even if it is not shown?

Of course. The code just delays freeing the old list until after the
new one has been created and accepted (by compstate[old_list] != keep).

> > So, does that thing with allowing completions added separately to be
> > offered together with a string with all completions sound too esoteric
> > or do you really like it. And should we then put it into _complete? (I
> > mean, the weekend is coming up, so I should have the time to try to
> > implement it... ;-)
> 
> I probably won't use it, but won't object, of course.

I already decided to play a bit to see how difficult to implement this 
is (both in C and shell code).

Bye
 Sven


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

Re: PATCH: _expand, _expand_word, and their doc

[Bart Schaefer]

On Oct 6, 10:14am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} > } > What would you (or anyone else) think of removing
} > } > insert-all-completions from _expand entirely (thus eliminating
} > } > the -c option) and instead put compstate[insert]=all at the end
} > } > of _expand_word (after _main_complete)?
} 
} Anyway. The reason why I don't really like the completions style to be 
} handled there is that -- as Andrej mentioned once -- the matches are
} generated different than the expansions. Not even by _expand itself
} (which just looked like a clever trick at that time).

Hm.  I don't have any overwhelming disagreement with that; the issue is
not so much that _expand_word should handle it, as that _expand should
not -- Andrej is clearly correct that _match is what actually does the
most-correct thing in terms of generating the possible completions, so
the question is how to get them all (offered to be) inserted at once.

} So, I would mainly vote for changing the way the completions are
} generated, using the way we do it in _prefix and _ignore, only the
} other way round. I.e. we look up the completer style in the new
} context and use the global list if it isn't set there. From that list
} we remove the `uninteresting' completers as Bart did in _e_w (_prefix
} and _ignore should probably do the same). That way the whole thing
} would be self-contained again.

I really am not entirely happy with the trick I used in _e_w.  What it
really should do is simply allow the completions to be generated the
usual way and then stuff them all as a single match into a new group
that could be named in the tag-order style (e.g. the expansion wouldn't
appear if that style wasn't named in tag-order).

} Then we leave it either in _expand or put it into a separate
} completer, depending on how strongly people feel that this is
} different from what _expand does [...].

I'd say we should use a new completer which has to appear very late in
the completer list, and which modifies the handling of the completions
that are generated before it is called.  As you suggest here:

} [...] And I think it would be possible, probably by adding 
} a new option to compadd which makes it add a string with all matches
} generated so far (and then remove the `all' special value for
} compstate[insert]).

The only issue with removing the "all" special value is that we still
should be able to express the idea that all the completions should be
immediately inserted.  If I understand your suggested change to compadd
correctly, we'd just end up with all the completions as an *additional*
choice.

} With that, it would almost make sense to add that feature to _complete
} itself, making it look (feature-wise) more like _expand.

I don't think adding it to _complete is good enough, in particular because
one may want to add all the completions generated by _match, which is not
usually called until after _complete.

On Oct 6,  4:34pm, Andrej Borsenkow wrote:
}
} > > You're starting from an initial pattern and expanding it into
} > > a set of strings, aren't you? What difference does it make
} > > whether the way you got those strings was by globbing, parameter
} > > substitution, history, or by invoking the completion system, or
} > > anything else?
} 
} Pragmatical answer: because currently we can select between individual
} expansions or all expansions, but cannot do it with completions.

That's a non-answer: _expand_word does NOT select between individual
expansions or all expansions.  It just inserts all of them.  So I ask
again, why does it matter where "all of them" came from?

The difficulty of course is that only "completion widgets" can be used to
generate completions, so you have to go through the completion system even
if what you want in the end is expansion.

} Metaphysical answer: I always considered expansion to be complementary
} to completion. Completion is always context-sensitive (in the very
} broad sense sometimes). We select from the fixed set of possible
} values; this set depends on context but values itself do not depend on
} initial pattern. With expansion we just evaluate the pattern; thus,
} the set of values does not depend on context in any way, but values
} itself obviously depend on initial string.

I don't agree with this.  Globbing, for example, is a context in which
the fixed set of possible values are files on the file system.  The glob
pattern doesn't create the values, it just selects the interesting ones.
So you've just argued that "filename generation" should not be considered
expansion, either -- but generating filenames is something that "expand",
in the expand-or-complete sense, has always done.

} Exactly the fact that completion is context-dependent action makes it
} possible (in most cases) to group matches, to provide decriptions etc.
} All this is inherently impossible with expansions, that do not have
} any internal structure (the only sensible way to group them is by the
} way intial string is evaluated - globbing, parameter expansion - that
} is done currently).

This might be an argument for why the _expand completer should not exist
but I don't find it relevant to the question of why _expand_word should
not be used to generate completions.

On Oct 6,  3:00pm, Sven Wischnowsky wrote:
} 
} I already decided to play a bit to see how difficult to implement this 
} is (both in C and shell code).

Then once again I'm probably a bit late with this reply, but ...

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: _expand, _expand_word, and their doc

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> Then, there was a completely inaccurate remark about the expansions and
> all-expansions tags in the doc:  They're *not* available when using the
> completions style with _expand.  If that's a bug in _expand rather than
> in the doc, I can't immediately see how to fix it ... so I changed the
> doc, and maybe Sven will do something to _expand when he returns.

I stumbled over this, too, when reading the manual while I was away.

I don't see a way to implement such a behaviour (i.e. I'm pretty sure
it isn't possible currently). So, Bart's changes, both in the docs and 
in _expand(|_word) are fine.

But of course I may start to think if this could be implemented -- if
I find a not-too-complicated way for changing the C-code...

Bye
 Sven


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

Re: PATCH: _expand, _expand_word, and their doc

[Bart Schaefer]

On Oct 5, 10:13am, Sven Wischnowsky wrote:
} 
} So, Bart's changes, both in the docs and in _expand(|_word) are fine.

What would you (or anyone else) think of removing insert-all-completions
from _expand entirely (thus eliminating the -c option) and instead put
compstate[insert]=all at the end of _expand_word (after _main_complete)?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: PATCH: _expand, _expand_word, and their doc

[Andrej Borsenkow]

>
>
> On Oct 5, 10:13am, Sven Wischnowsky wrote:
> }
> } So, Bart's changes, both in the docs and in _expand(|_word) are fine.
>
> What would you (or anyone else) think of removing insert-all-completions
> from _expand entirely (thus eliminating the -c option) and instead put
> compstate[insert]=all at the end of _expand_word (after _main_complete)?

What has inserting all *completions* to do with *expansions* (and thus
_expand_word)? Even less than with _expand completer. IM very strong O this
simply should be another widget.

I am sorry, I was a bit off this list and leaved _insert_all_completion
unfinished. But I still like the idea of respecting existing list (so you
could use it not only initially) and it needs some guard against
_correct/_approximate (where generated lists are not much useful for
insertion).

-andrej

Re: PATCH: _expand, _expand_word, and their doc

[Bart Schaefer]

On Oct 5,  7:34pm, Andrej Borsenkow wrote:
}
} > What would you (or anyone else) think of removing insert-all-completions
} > from _expand entirely (thus eliminating the -c option) and instead put
} > compstate[insert]=all at the end of _expand_word (after _main_complete)?
} 
} What has inserting all *completions* to do with *expansions* (and thus
} _expand_word)?

You're starting from an initial pattern and expanding it into a set of
strings, aren't you?  What difference does it make whether the way you
got those strings was by globbing, parameter substitution, history, or
by invoking the completion system, or anything else?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

PATCH: _expand, _expand_word, and their doc

[Bart Schaefer]

Way back in 11244, Sven wrote:

} However, there was a problem I didn't realise before. With completions 
} set _expand just returned with a value of one to make the following
} completers be called. But with _expand_word there aren't any following 
} completers... So the patch makes _expand call _complete when called
} from _expand_word.

This has the undesirable side-effect of failing to call any of the usual
other completers such as _match (see zsh-users/3444 and its thread).  So
I've deleted that line from _expand, and instead caused _expand_word to
fetch the `completer' style and modify the result so that _expand is the
first completer in the list.  This is imperfect, as it discards the entire
list if you haven't included the _expand completer at all, but I couldn't
think of any better way to assure that unwanted completers such as _list
and _menu are excluded.

Then, there was a completely inaccurate remark about the expansions and
all-expansions tags in the doc:  They're *not* available when using the
completions style with _expand.  If that's a bug in _expand rather than
in the doc, I can't immediately see how to fix it ... so I changed the
doc, and maybe Sven will do something to _expand when he returns.

Index: Completion/Commands/_expand_word
===================================================================
@@ -6,6 +6,7 @@
 unsetopt markdirs globsubst shwordsplit nounset ksharrays
 
 local curcontext="$curcontext"
+local -ah completers
 
 if [[ -z "$curcontext" ]]; then
   curcontext="expand-word:::"
@@ -13,4 +14,8 @@
   curcontext="expand-word:${curcontext#*:}"
 fi
 
-_main_complete _expand
+zstyle -a ":completion:${curcontext}:" completer completers
+completers[1,(i)_expand]=_expand
+(( $#completers == 1 )) && completers=(_expand _complete)
+
+_main_complete $completers
Index: Completion/Core/_expand
===================================================================
@@ -23,7 +23,6 @@
 if [[ "$force" = *c* ]] ||
    zstyle -t ":completion:${curcontext}:" completions; then
   compstate[insert]=all
-  [[ "$curcontext" = expand-word:* ]] && _complete && return 0
   return 1
 fi
 
Index: Doc/Zsh/compsys.yo
===================================================================
@@ -971,7 +971,8 @@
 This style is used by the tt(_expand) completer function. If it is set 
 to `true', the completer will not generate expansions, but instead the
 completions will be generated as normal and all of them will be
-inserted into the command line.
+inserted into the command line.  This style is most useful when set
+only for very specific completion contexts.
 )
 kindex(condition, completion style)
 item(tt(condition))(
@@ -2302,10 +2303,9 @@
 Which kind of expansion is tried is controlled by the tt(substitute),
 tt(glob) and tt(subst-globs-only) styles.
 
-There is another style, tt(completions), which allows tt(_expand) to
-display or insert all em(completions) generated for the string.  The use of
-this is that the tags tt(expansions) and tt(all-expansions) are available,
-unlike with tt(_complete).
+There is another style, tt(completions), which causes tt(_expand) to
+unconditionally insert all em(completions) generated for the current
+word (even if the word is empty).
 
 When tt(_expand) is called as a function, the different modes may be
 selected with options.  The tt(-c) corresponds to the tt(completions)
@@ -2485,7 +2485,11 @@
 item(tt(_expand_word (^Xe)))(
 Performs expansion on the current word:  equivalent to the standard
 tt(expand-word) command, but using the tt(_expand) completer.  Before
-calling it, the var(function) field is set to `tt(expand-word)'.
+calling it, the var(function) field is set to `tt(expand-word)', and the
+list of functions from the tt(completer) style in the resuting context is
+shifted to remove all those to the left of tt(_expand).  If tt(_expand)
+does not appear in the style, then only the two completers tt(_expand) and
+tt(_complete) are used (in that order).
 )
 findex(_generic)
 item(tt(_generic))(

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: _expand, _expand_word, and their doc

[Bart Schaefer]

On Sep 20,  5:57pm, Bart Schaefer wrote:
}
} This has the undesirable side-effect of failing to call any of the usual
} other completers such as _match (see zsh-users/3444 and its thread).  So
} I've deleted that line from _expand, and instead caused _expand_word to
} fetch the `completer' style [...]

Except I forgot that this is only supposed to happen when the completions
style is set.  Sorry about that.

Index: Completion/Commands/_expand_word
===================================================================
@@ -14,8 +14,12 @@
   curcontext="expand-word:${curcontext#*:}"
 fi
 
-zstyle -a ":completion:${curcontext}:" completer completers
-completers[1,(i)_expand]=_expand
-(( $#completers == 1 )) && completers=(_expand _complete)
+if zstyle -t ":completion:${curcontext}:" completions; then
+    zstyle -a ":completion:${curcontext}:" completer completers
+    completers[1,(i)_expand]=_expand
+    (( $#completers == 1 )) && completers=(_expand _complete)
+else
+    completers=(_expand)
+fi
 
 _main_complete $completers
Index: Doc/Zsh/compsys.yo
===================================================================
@@ -2485,11 +2485,13 @@
 item(tt(_expand_word (^Xe)))(
 Performs expansion on the current word:  equivalent to the standard
 tt(expand-word) command, but using the tt(_expand) completer.  Before
-calling it, the var(function) field is set to `tt(expand-word)', and the
-list of functions from the tt(completer) style in the resuting context is
-shifted to remove all those to the left of tt(_expand).  If tt(_expand)
-does not appear in the style, then only the two completers tt(_expand) and
-tt(_complete) are used (in that order).
+calling it, the var(function) field is set to `tt(expand-word)'.
+
+The tt(completions) style is also tested in the resulting context.  When
+it is true, the list of functions from the tt(completer) style is shifted
+to remove any that would be called ahead of tt(_expand).  If tt(_expand)
+does not appear in the tt(completer) style, then only the two completers
+tt(_expand) and tt(_complete) are used (in that order).
 )
 findex(_generic)
 item(tt(_generic))(

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: PATCH: _expand, _expand_word, and their doc

[Andrej Borsenkow]

> +inserted into the command line.  This style is most useful when set
> +only for very specific completion contexts.

I continue to ask myself just how useful it is.

completions style is tested only in _expand. It is either called from
_main_complete or directly (currently from _expand_word only). At the time
when completions style is tested, context is

:completion::expand::

-or-

:completion:expand-word:expand::

(I just realized, that completer has fixed value in this case :-)

Even if _main_complete would have set command name, the most sepecific context
would be

:completion:*:expand:${command_name}::

Anything more specific is set (if ever) only inside of per-command competion
function. It means, that at most you can request insertion of all completions
for a given command. It is very unlikely that anybody ever really wants it.
While in case of 'cvs rm TAB' insertion is appropriate, it is hardly useful in
case of 'cvs -TAB'. And currently even this is not possible - at most you can
state that all completions should be inserted for a given widget :-))

Unless I again miss something obvious.

-andrej

Re: PATCH: _expand, _expand_word, and their doc

[Bart Schaefer]

On Sep 21, 10:33am, Andrej Borsenkow wrote:
} Subject: RE: PATCH: _expand, _expand_word, and their doc
}
} > +inserted into the command line.  This style is most useful when set
} > +only for very specific completion contexts.
} 
} I continue to ask myself just how useful it is.

I suspect it's intended to be used in the :completion:expand-word:expand::
context, though I didn't realize the context never gets any more specific
than that.  That way the user can decide whether to invoke it.

If it would work to set compstate[insert]=all inside _expand_word, before
calling _main_complete, then we could do that instead and remove the
handling for that style from _expand.  I don't have time today to try
this.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: PATCH: _expand, _expand_word, and their doc

[Andrej Borsenkow]

>
> On Sep 21, 10:33am, Andrej Borsenkow wrote:
> } Subject: RE: PATCH: _expand, _expand_word, and their doc
> }
> } > +inserted into the command line.  This style is most useful when set
> } > +only for very specific completion contexts.
> }
> } I continue to ask myself just how useful it is.
>
> I suspect it's intended to be used in the :completion:expand-word:expand::
> context, though I didn't realize the context never gets any more specific
> than that.  That way the user can decide whether to invoke it.
>
> If it would work to set compstate[insert]=all inside _expand_word, before
> calling _main_complete, then we could do that instead and remove the
> handling for that style from _expand.  I don't have time today to try
> this.
>

It does work happily (look at my example _insert_all_matches in 12849).
Actually, it needs to be set after _main_complete (what counts, is the value
on return from completion widget). It needs some clean up, but it seems to
work in almost all contexts I tried (but see the list of problems there).

I send the patch against current CVS so you could look at it.

-andrej

Index: Completion/Commands/.distfiles
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/.distfiles,v
retrieving revision 1.4
diff -u -r1.4 .distfiles
--- Completion/Commands/.distfiles	2000/06/19 09:16:17	1.4
+++ Completion/Commands/.distfiles	2000/09/21 14:57:28
@@ -2,5 +2,5 @@
     .distfiles
     _bash_completions _complete_debug _correct_filename _correct_word
     _expand_word _history_complete_word _read_comp _most_recent_file
-    _complete_help _next_tags _complete_tag _generic
+    _complete_help _next_tags _complete_tag _generic _insert_all_matches
 '
Index: Completion/Commands/_insert_all_matches
===================================================================
RCS file: _insert_all_matches
diff -N _insert_all_matches
--- /dev/null	Tue May  5 13:32:27 1998
+++ _insert_all_matches	Thu Sep 21 07:57:28 2000
@@ -0,0 +1,35 @@
+#compdef -K _insert_all_matches complete-word \C-xi
+
+setopt localoptions nullglob rcexpandparam extendedglob noshglob
+unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
+local oldcurcontext="$curcontext" list ret
+
+if [[ -z "$oldcurcontext" ]]; then
+  curcontext="insert-all-matches:::"
+else
+  curcontext="insert-all-matches:${oldcurcontext#*:}"
+fi
+
+zstyle -s ":completion:${curcontext}:" old-list list
+
+# If there is already an old list,
+# and either the style :insert-all-matches:old-list is `always',
+# or it is not `never', then insert the existing list
+# (even if it was generated by another widget).
+# Else just call completion and insert whatever matches it generated
+# TODO: does not work in menu selection
+
+
+if [[ -n $compstate[old_list] && $list != never &&
+      $LASTWIDGET != _complete_help && $WIDGET != _complete_help ]]; then
+    compstate[old_list]=keep
+    compstate[insert]=all
+    return 0
+else
+    curcontext="$oldcurcontext"
+    _main_complete
+    ret=$?
+    compstate[insert]=all
+    return $ret
+fi
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.96
diff -u -r1.96 compsys.yo
--- Doc/Zsh/compsys.yo	2000/09/21 05:16:22	1.96
+++ Doc/Zsh/compsys.yo	2000/09/21 14:57:34
@@ -1614,7 +1614,10 @@
 )
 kindex(old-list, completion style)
 item(tt(old-list))(
-This is used by the tt(_oldlist) completer.  If it is set to `tt(always)',
+This is used by the tt(_oldlist) completer and tt(_insert_all_matches)
+bindable command.
+
+For tt(_oldlist) if it is set to `tt(always)',
 then standard widgets which perform listing will retain the current list of
 matches, however they were generated; this can be turned off explicitly
 with the value `tt(never)', giving the behaviour without the tt(_oldlist)
@@ -1626,6 +1629,11 @@
 old list will be used even if it was generated by a widget which does
 not do listing.

+For tt(_insert_all_matches) if it set to `tt(never)', tt(_insert_all_matches)
+will always generate new list. If this style is unset or with any other
+value it will reuse existing list if available. It has the same caveats
+as in case of tt(_oldlist).
+
 For example, suppose you type tt(^Xc) to use the tt(_correct_word)
 widget, which generates a list of corrections for the word under the
 cursor.  Usually, typing tt(^D) would generate a standard list of
@@ -2511,6 +2519,18 @@
 item(tt(_history_complete_word) (\e/))(
 Complete words from the shell's command history. This uses the
 tt(list), tt(remove-all-dups), tt(sort), and tt(stop) styles.
+)
+findex(_insert_all_matches) (^Xi))
+item(tt(_insert_all_matches) (^Xi))(
+Insert all generated matches into command line. If used after any
+completion widget, it normally will reuse old list even if menu completion
+was already started (this is controlled by old-list style), else it will
+call normal completion to generate matches.
+This uses the tt(old-list) style. It sets var(function) field
+to tt(insert-all-matches) when looking up the style and resets this
+field to its original value before calling completion.
+
+Note, that it currently does not work in menu selection.
 )
 findex(_most_recent_file (^Xm))
 item(tt(_most_recent_file (^Xm)))(