From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10809 invoked from network); 11 Feb 2000 12:41:06 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Feb 2000 12:41:06 -0000 Received: (qmail 11097 invoked by alias); 11 Feb 2000 12:41:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9679 Received: (qmail 11089 invoked from network); 11 Feb 2000 12:40:59 -0000 Date: Fri, 11 Feb 2000 13:40:58 +0100 (MET) Message-Id: <200002111240.NAA30094@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Fri, 11 Feb 2000 14:40:19 +0300 Subject: RE: PATCH: yet another completer (with PATCH) 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@informatik.hu-berlin.de