Re: Random comments about matchers

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> 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 :-)

(You mean `_match_pattern' here, I think.)

We could document it more verbosely, and it's much easier to do this
for a given matcher than writing something general (and *much* faster).

> 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 ...

There is `compstate[matcher_string]', giving the *string* of the
currently used global matcher.

> 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?

But with a `_match_pattern' comparable to the global matcher this
should still work.

> 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 ...

Yes, but see below.

> 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 ...

For some of the things matchers are used for I really don't think that 
using them in completion functions is the right place, but instead the 
global matchers are the right thing to use (case-insensitivity,
shortcut-keys, even some of the partial-word-thingies).

> 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).

Robust? Depends on your `_match_*' functions, I'd say ;-)

> 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 :-)

I don't know how useful it would be, but it would be amazingly hard. I 
think I said this already, but anyway: when I first collected ideas
for this matching stuff I thought a lot about using the globbing code
for it, but then found too many problems.

The matcher code in tricky.c has to deal with two strings and two
patterns at the same time -- very different from the globbing
code. The code has to build a matching string (different, since
globbing only has to test existing strings) and it also has to collect 
a different kind of information: the cline structs I've already been
talking about. They are needed to be able to build the unambiguous
string.

Given all that I have to admit that I didn't thinnk about making the
globbing code call the completion code (and at that time we didn't
have the `(#...)' globbing flags), only the other way round. Still,
there is a problem: the globbing code is in the main zsh code, while
completion is in a module and of course we don't want to put the
completion code back into the basic shell. Of course, if we find uses
where what you suggested might be useful anyway, we could think about
moving part of the completion matching stuff there, but currently I
see nothing where this might be interesting to have.

Anyway, I'll have to think about this some more (and would like to
hear about cases where such a pattern-matching enhancement might be
useful).

> 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' ...).

I think you mean shell code here... that's already possible.
Implementation is left as an exercise to the reader. 

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

See above: `compstate[matcher_string]'.

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

If a user writes his own function he can easily add the `-M...' directly.

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

I don't think I understand this one -- there is currently only one
function that has to be altered by the user.

>  - (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.

Ah, maybe you didn't mean shell code... but the completion (C-) code
doesn't know from which function it's called (and it shouldn't know).

> Well, I don't know, to which extent is it doable - but, as said, the current
> state probably needs some more think about ...
> 
> ...
> 
> 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 ...

I once suggested (with code) a much simpler matching-stuff
implementation allowing (roughly) what you said, but that didn't get
included.

Also, when suggesting the current implementation, I asked for help on
the syntax -- and got only a sarcastic reply from Bart (Hi Bart, sorry 
Bart ;-). Adding syntactic sugar for the simple cases would be easy,
just go ahead and make suggestions (and there even *is* already
syntactic sugar -- the colon).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx