Re: PATCH: _expand, _expand_word, and their doc

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx