From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19932 invoked from network); 4 Oct 2000 11:15:50 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Oct 2000 11:15:50 -0000 Received: (qmail 22422 invoked by alias); 4 Oct 2000 11:14:50 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 3448 Received: (qmail 22414 invoked from network); 4 Oct 2000 11:14:49 -0000 Date: Wed, 4 Oct 2000 13:14:20 +0200 (MET DST) Message-Id: <200010041114.NAA09467@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-users@sunsite.auc.dk In-reply-to: "E. Jay Berkenbilt"'s message of Sun, 17 Sep 2000 19:03:05 -0400 Subject: Re: completion with globbing, take 2 E. Jay Berkenbilt wrote: > ... > > _main_complete is called. It looks up my completers (_oldlist, > _complete, _expand, and _match) and calls then in order. _oldlist > returns nothing, _complete returns nothing (since no files start with > '*'). Now it starts getting interesting. _expand is called. Since I > have set the completions style for expand to true, it sets > compstate[insert]=all which gives me the behavior I'm looking for with > respect to the replacement. However, since the current context is not > expand-word:*, it does not call _complete and thus just returns 1. > Finally, _match is called. I don't follow exactly what's going on at > the top of _match, but it doesn't matter. Since I don't have > match-original set, _match sets compstate[pattern_match]='*' and calls > _complete again. This time, since compstate[pattern_match] is set, > _complete actually does find matches. > > So the right thing happens, but the path to the desired end seems > quite convoluted and counterintuitive to me. I would never have > figured this out without the significant hints without having to spend > a lot of time grokking this code. The first thing is that _expand is intended to be in the completer list *before* _complete. And it was documented that way. The other thing is that this kind of use, as you all found out, doesn't really have anything to do with expansion and hence doesn't need a pattern on the line -- which lead to _expand being used in combination with _match and all that. Hm. Maybe we should make the completer-handling of _expand with the completions style set more clever. Or something. Probably together with Bart's changes to _expand_word. I'll have a look. I'll avoid digging through all the other messages in this thread again, only one more remark: Of course, the (implementation of the) completions style is a bit hackish. And, more importantly, it was never intended to be set unconditionally. Not too long a go, it was one of the mathematically- conditional styles (if you don't know what that was, don't mind). Nowadays it is intended to be used either with `zstyle -e' (where one could, inter alia, have a look at the command line with $words, $BUFFER or $PREFIX (to see if the word is a pattern or some such)) or with, e.g., _generic, as in: zle -C complete-all complete-word _generic bindkey '^xa' complete-all zstyle ':completion:complete-all:*' completer _expand _complete zstyle ':completion:complete-all:*' completions yes Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de