Re: 3.1.6-dev-18

[Peter Stephenson <pws@pwstephenson.fsnet.co.uk>]

Sven Wischnowsky wrote:
> I can only repeat... I would have no problems with turning the matcher 
> style as used by _matcher (or even renaming it for clarity) into one
> that is used as an array. The first _matcher would then use the first
> string in the value, the second one the second string and so on. I
> just thought -- and I may very well be wrong here -- that it would
> make users more aware of what they are doing if we use this more
> explicit setting we have now. I.e., even with the suggested
> array-interpretation of the matcher style one would have to add a new
> call to _matcher in the completer list when adding a new string to the 
> matcher style.

Given the last sentence, your way of doing things does make more sense.
But I appreciate Andrej's point that the _matcher completer ideally
shouldn't be necessary at all, given that there's a style controlling it.
If there is some magic which could go in, say, _main_complete to handle
this, it would be nice.  For example, start with matcher-1, try with that;
then retrieve matcher-N, continuing until either you get the same string as
before (assumption: there was a * in the matcher column), or you get
nothing (assumption: the style's not set at all); plus do some optimisation
based on which completers don't use matching at all, to avoid calling
completers unnecessarily.

On the other discussion, I'm certainly not hung up on providing
alternatives to the string context, which I think is pretty usable when you
get your mind round it.  It's more a question of what the punters think
than what I think.

By the way, should there be a style that says that old-style completions
are to be used?  It would avoid the necessity of customizing _default.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>