RE: PATCH: yet another completer (with PATCH)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> > +
> > +example(zstyle ':completion:::::' completer _matcher _complete
> > _matcher _complete
> > +zstyle ':completion:*:matcher-1:::' matcher 'm:{a-z-}={A-Z_}'
> > +zstyle ':completion:*:matcher-2:::' matcher 'm:{a-z-}={A-Z_}'
> > 'r:|[-_./]=* r:|=*')
> > +
> 
> Question(s) and comment(s).
> 
> - Is it posssible to set match specs on per-command/per-argument basis? In
> this case, it is better to include such example. Current one implies, that
> you can only set globally valid match specs.
> 
> - The most common case so far is file name completion. Can I set default
> match specs for _path_files only? That is, default match specs that affect
> only file names but not anything else - non-file arguments, options etc

For both questions: that's the job of the matcher style as it is used
for tags.

However... I've already wished one could define some other styles on a 
per-command basis. This always reminds me of the discussion we had
when I starting working on the tags stuff. Maybe we should move the
context-finding code from _complete and _normal somewhere else. Maybe
even into _main_complete (or a utility function) so that the context
is set up more precisely from the beginning. Functions like _cvs would 
still modify the context name (inserting the sub-command name and
things like that), but that's all right I'd say. The effect would be
to make the `phases'-model of the completion code cleaner, separating
out most of the context-finding code into its own phase instead of
interweaving it with the completion-generation phase. Hm, this sounds
as if Bart would like it and if Bart likes something its normally a
good idea to do that (I know that because I've forgotten to do that
too often).

Note however, that the matcher style used in _desription would still
make sense because at that time we even know the tag -- something we
can't find out at the beginning of the completion code.

> - This is nice as long as you have just a single completer ... but I have
> e.g.
> 
> zstyle ':completion:*' completer _oldlist _complete _match
> 
> If I want to use two different matchers, should I now write
> 
> zstyle ':completion:*' completer _matcher _oldlist _complete _match _matcher
> _oldlist _complete _match
> 
> Looks at least weird.

It's only really useful for _complete and _prefix (if that calls
_complete). All other completers either don't generate matches (and
hence never use match specs) or use glob-style matching (and hence
don't use match specs either).

> - This has the same pitfall as global match specs before - it is
> position-dependent. Imagine, that I have to matchers and want to add one
> more in between. Now, I have to change matcher-2 into matcher-3 in all
> styles!

Err... it's only one style. So `insertion of a new match spec' amounts 
to inserting `_matcher' in the completer list copy one of the
matcher-style lines and editing it. How often do you change your
global match specs?

> I'd prefer something like "match specs list" - list of match specs that
> would be tried until any matches are found. Probably, on per-completer
> basis. Or is it intended to be used (useful) only with _complete? Even then
> the
> 
> zstyle ':completion:*:complete:::' match_specs_list 'm:{a-z-}={A-Z_}' ...
                                          ^     ^
                                            urgh!
> is much cleaner than
> 
> zstyle ':completion:*' completer _matcher _complete _matcher _complete
> _match
> zstyle ':completion:*:matcher-1:::' matcher 'm:{a-z-}={A-Z_}'
> zstyle ':completion:*:matcher-2:::' matcher 'm:{a-z-}={A-Z_}' 'r:|[-_./]=*
> r:|=*')

Actually, I first implemented it with a `matcher' and a `completer'
style. The latter defaulted to `_complete' and the former was looked
up as an array and the strings in the value where then used in a loop
that called the completers. Then I thought that we were almost in a
position to remove $compmatchers but for that it would be nice to have 
a way to define a match specs that is to be used `from now on'.
Otherwise one would have to define a global completer containing only
_matcher (or _oldlist and _matcher) and then put the completers one
would really want to use into the completer style for _matcher. That's 
far too ugly. So my next idea was to allow an empty completer style
for _matcher to mean: set the match spec globally, meaning: use it for 
all following completers (in the global completer) list. Thank god I
then woke up and realised that this means that we really don't need
the `local' mode, i.e. the completer style used by _matcher.

So, it would be easy to change _matcher to use the value of the
matcher style differently, i.e. make it take it as an array again and
make it use the first string on the first invocation, the second one
on the second invocation and so on. But note that one would still have 
to give _matcher multiple times in the global completer list and that's
why I'd like to keep the current state: make it explicit in both the
completer list and the styles for _matcher. Otherwise people might
just set the matcher style for _matcher, forget to change the
completer list and then wonder why this doesn't work.

I would like to hear other opinions... Of course we can also go back
to the two-modes model, i.e. add a style completer for _matcher and if 
that is set (empty value measn `_complete'), make it call the
completers directly, using the strings in the matcher style value one
after another. Hm. Or better add another style `matcher-list' or
whatever and if that is set for the n'th call to _matcher...


The patch just tries to make things a bit clearer.

Bye
 Sven

diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Fri Feb 11 11:59:10 2000
+++ Doc/Zsh/compsys.yo	Fri Feb 11 13:30:30 2000
@@ -1606,6 +1606,12 @@
 tt(_matcher), this has the same effect as setting it to the empty
 string: it makes the following completion function not use any match
 specifications besides those used by the functions themselves.
+
+Note that currently only the tt(_complete) completer and the
+tt(_prefix) completer (if it has its own tt(completer) style
+containing tt(_complete)) use the match specifications, so one doesn't 
+need to repeat all completers one wants to use after each call to
+tt(_matcher) in the completer list.
 )
 findex(_expand)
 item(tt(_expand))(

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx