Re: zsh-3.1.2-zefram3

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

Andrew Main wrote:

>...
>
> N  3503 wischnow lots of nifty completion options
> 	This I did not include.  AUTO_GLOB_COMPLETE really has very
> 	little to do with GLOB_COMPLETE -- all it does is complete from
> 	the beginning of the word as well as the end.  This is the sort
> 	of thing that multicomp is for.  COMPLETE_FOLD_CASE I would
> 	have used had it been separate from the rest of the patch; it
> 	does something useful that can't easily be done in user space.
> 	The other compctl options (-. and -:) I do not like.  They seem
> 	to require an awful lot of code for something that, again,
> 	should really be part of a completion function.
> 

I'm all for doing this in shell functions, but zsh isn't strong enough
for that (yet). The problem is that things like multicomp only work
with menu-completion.

Question is, what excatly do we need to allow building arbitrary
completion lists in shell functions and have the code make them
conveniently accessible with normal completion. Maybe something like
`replace the current word with the prefix <a> and the suffix <b>,
placing the cursor between them'. But we would also need to be able to
return the whole completion list for automenu. Taking multicomp
(i.e. path) completion as an example that would mean to present either
the list of full paths or only the list of ambiguous path name
components.
Thinking about the latter leads to the suggestion that such functions
may return: `we split the current word into <prefix><ambig><suffix>
at positions <p0> and <p1> and want <prefix> be replaced by <a>,
suffix by <b>, and for <ambig> we offer the list of possible
completions in $reply, now present that to the user'. But that sounds
pretty complex (in fact this is near to what the compctl code does
internally), so does anyone see a simpler solution?


Bye
 Sven


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