Re: PATCH: _expand, _expand_word, and their doc

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

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