Random comments about matchers

["Andrej Borsenkow" <borsenkow.msk@xxxxxx>]

Looking at the examples more closely over the weekend (and trying to do
something useful myself :-) I'm still feeling uneasy about how matchers are
currently implemented ...

1. Currently users are expected to translate matcher desription into glob
pattern(s). I'm afraid, it is sometimes not trivial for normal users (I
don't claim, that matcher specs are trivial either :-)

2. It is possible to use matchers only with completion function(s) that do
matching. In other words, we need one matcher definition for "normal"
completion and one glob pattern for "matching" one.

3. When testing for global matcher, we basically rely on order of
definitions to select needed one(s). Inserting a matcher in global array
will potentially cause havoc ...

4. And, 'course, the problems in _path_files again and again ... Yes, I
know, the known :-) problems seem to be gone now ... but, really, user can
after all five _any_ pattern on command line. Or?

5. Sometimes we need matching in more tan one place (yes, this is a variant
of 2). Consider _long_options - we test given string against options array
and in another place we simply add it using compadd with matcher. Looks
naturally to use the same mechanism in both cases ...

6. I have the feeling, that we test for matchers in wrong place! That is,
consider _path_files, _long_options etc. This functions are purely *helper*
functions - they actually have no idea (well, it is not entirely true in
case of _long_options ...) of what really is completed. The correct place to
set matchers is in functions that actually call these heplers ...

7. The code relies on exisiting of _match_test and _match_pattern ... not
that I much like it (it makes the code at least less robust).

So, I have here a suggestion for 2 and 5 (and probably 4), rather vague idea
for 1, 3 and 6.

2,4,5 How hard (and useful) is to add matchers to a globbing flags?
Something, like
(#m(matcher spec))? The code seems to be there all right ... 'course, we
probably want low/upper versions to be the same (that is, just match but not
replace). In this way it will be possible to have a _single_ matcher spec,
that can be used with both globbing and non-globbing completion (and,
probably, useful outside completion as well). Consider bindkey example -
this would allow users to set matcher, that will be equally usable in all
cases (and then I agree, that explicit matches in functions are evil :-)

1,3,6 A somewhat vague idea is

 - use global matchers hash where keys are function names )_bindkey,
_configure etc) and values are matcher specs. We can add global matchers
with special keys (the simplest is `1', `2' ...).

 - and define some (compstate?) parameter with meaning "current matcher(s)
to use"

It would allow

 - easy cutomisation. User writes it's own function and simply sets
matchers[_my_func] to whatever matchers (s)he likes

 - more (IMHO) robust. In this way we could move all code that tests
for/sets matchers in several basic functions

 - (combining with tee first part) setting matchers[] would provide for
unanimous habdling in both builtin and function code *irrespectively* of
wether we use globbing or simple completion.

Well, I don't know, to which extent is it doable - but, as said, the current
state probably needs some more think about ...

cheers

/andrej

P.S. I forgot about 1. Well, So far the matchers are most commonly used for:

1. ignore the specified string
2. case insensitive matching
3. mutlipart matching (with separator)

May be, if there were some simple way to tell exactly that (without all
hassle with patterns etc) it would be much more useful for end-users ...

P.P.S.

Sven, thank you once more. Probably, I'd put this in my signature :-)