RE: 3.1.6-dev-18

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

Andrej Borsenkow wrote:

> ...
> 
> When I spoke about array, I meant absolutely different thing. Remove
> _matcher completer alltogether. Setup a style with match specs, that will be
> tried in order. In other words
> 
> zstyle :completion::complete::::: match_specs "" spec1 spec2 ...
> 
> with semantics
> 
> _complete should try this list in order until it gets matches.

Currently it is only _complete. But noone knows if in the future we
may have other completers that could take advantage of match specs.

Also, if we put it into _complete, you'll always get the match specs -- 
if it is called from _main_complete or _prefix or from whereever
else (so we would at least have to make it test if we are currently
doing correction or approximation and avoid the loop then). In other
words, controlling the match specs would -- in my opinion -- be even
less obvious than it is now.

> I agree, that your way provides more fine grained control ... the question
> is, how complex completion system is going to be? Do you think, that an
> everage user would ever need such a complexity?

`need' is a dangerous word... I think users would like to be able to
control exactly when which match specs are used, even if only for
performance reasons. I'm planning to go through the manual at least
once more (and through Peter's guide when it's there), trying to make
things like this clearer (more examples, at least).

> And what occured to me ... why _oldlist, _prefix etc are completers at all?
> They look much more like actually a styles to me! They do not generate any
> matches - rather, they say completion system _how_ to generate matches. So,
> somewhat revolutionary ;-) idea:

Well, since _prefix calls the completers one could say that it does
generate matches -- in the same way _correct and _approximate do.

For things like _oldlist... it's mostly a matter of trying to make
things cleaner and cheaper. Putting things that are similar into a
separate module instead of having one monster-module that can do
everything (otherwise we could just have a builtin with lots of
options...). And putting things into separate functions means that
only people that *want* the behaviour have to pay for it, at least in
terms of execution speed.


Bye
 Sven

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