RE: PATCH: _expand, _expand_word, and their doc

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

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