From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22358 invoked from network); 15 Jun 2000 15:16:17 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Jun 2000 15:16:17 -0000 Received: (qmail 23694 invoked by alias); 15 Jun 2000 15:16:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11931 Received: (qmail 23682 invoked from network); 15 Jun 2000 15:15:45 -0000 Date: Thu, 15 Jun 2000 17:15:32 +0200 (MET DST) Message-Id: <200006151515.RAA11404@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Oliver Kiddle's message of Thu, 15 Jun 2000 15:54:23 +0100 Subject: Re: PATCH: Re: expansion Oliver Kiddle wrote: > Sven Wischnowsky wrote: > > > > Yes, I think I said that the patterns could do with a little improvement. > > Yes, and there is still scope for more improvements. Does anyone know > which characters terminate a parameter reference which doesn't use > braces? Anything but [a-zA-Z0-9_], except for the special one-character parameters and the `:...' modifiers if we want to deal with them. > > 2) Not using `recexact' as the style name was, of course, intentional, > > because it really isn't about `recognising', is it? It's about > > accepting the exact match (it will always take an exact match as > > one of the possible matches[1]). > > And accept-exact has the same meaning as recexact, we don't need to > > reverse it. > > Functionally, I can't see that there is a difference between recexact > and accept-exact. Are you basically saying that acceptexact would have > been a better name for the option as well? No, that was taken from elsewhere, I think (csh? tcsh?). But we are talking about `accepting' a match elsewhere, so... > > [1] Has anyone else wished he had a style to say `complete anything > > *but* an exact match'? > > We already have ignore-line... we could extend that. > > It took me a little while to work out what you mean by that but I can > see that it might be useful because someone might feel that they are > only going to press tab if they want to complete something. > > It seems to me that the choices are that if the current line is an exact > but ambiguous match, there are three choices: match only the current > exact match, match all matches or match all but the current exact match > so maybe a style with three possible values would be better. I want to integrate it with (the already existing) ignore-line style, three choices there: ignore all words from the line, ignore only the current word, ignore all words except the current one. > I actually got quite confused while trying to work out what happens in > different situations because of the line in _expand which prevents > substitutions expanding if they expand to an empty string and I was > using an empty variable. Maybe _expand should display a message in this > case. Or make it configurable... (this is getting out of hand). > > I didn't change that even now because I've regretted these > > `mathematically conditional' styles for quite some time now. They > > should be turned into boolean styles and the condition should come > > from somewhere else, e.g. the -e option to zstyle I suggested (see > > 11691). > > I meant to reply to that at the time because it seems like a good idea. > It would certainly be a lot cleaner if any sort of evaluations are built > in to zstyle and don't have to be repeated in completion functions. > > What exactly do you mean by the word evaluated when you say that 'the > resulting string will be evaluated' in the documentation in the patch: > is the idea that you would use a function. The -e option makes the values given when defining the style be concatenated with spaces between them and the resulting string eval'ed (i.e. exactly what the eval builtin does). > How would this affect the > functions which can be used for tag-order (which, if you remember I use > to avoid completing commands with an empty word). Not at all. Whatever the eval'ed code stores in $value/$reply is returned as the value of the style when it is looked up. In a certain sense it's just an extra level of indirection. > For styles whose > values are arrays, it would be useful to be able to return $value/$reply > as an array. Of course the patch already did that. Since I only used $value, not $VALUE, you may have guessed that the eval'ed code can return *only* arrays (well, ok, the contents of $value is only used as an array), just like styles do. Before the stuff is eval'ed, $value is unset (explicitly, by the zstyle-code). If it is left unset, this is as if the style weren't set, if $value is set to some value, it is treated as if that/those string/s were defined for the style without the -e option. > On the subject of the _expand not doing brace expansion, Sven wrote: > > > Change (e)? Use `eval echo ...'? Urgh? > > I think it would be a bad idea to change (e) and the eval is going to be > slow. I think I said it before a while ago but it would be nice if there > was clearly defined ways to do the various types of expansion, > individually or together. A (b) to do brace expansion might solve the > brace problem but we would maybe have fewer problems in _expand if there > was syntax like (e:pab:) to do parameter, arithmetic and brace expansion > with other letters for things like ~, =, history, command and whatever > other expansions we have. Well, history expansion at least has to be done before completion is tried because it's done by the lexer. The other thing: could get complicated to implement, I think (and using e:...: might cause trouble with existing uses unless we allow only a few special character as the separator; is E used?). > This would have some problems though: expansions which expand to things > which can be further expanded for example but I'd have thought these > have all be addressed in the code before. The other trouble with > expansion as a part of completion is that completion by definition deals > with things which are incomplete so we have the problem of what to do > with things which aren't syntactically correct yet. For example, try: > a( and you will get '_expand:78: bad pattern: a(' because of the > lack of a closing bracket. It doesn't anymore, (e) is silent nowadays. By using eval we could get that, though (that's why I said `careful'). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de