From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21592 invoked from network); 15 Jun 2000 14:54:36 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Jun 2000 14:54:36 -0000 Received: (qmail 21378 invoked by alias); 15 Jun 2000 14:54:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11929 Received: (qmail 21371 invoked from network); 15 Jun 2000 14:54:29 -0000 Message-ID: <3948EE1F.E4451C61@u.genie.co.uk> Date: Thu, 15 Jun 2000 15:54:23 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.73 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Zsh workers Subject: Re: PATCH: Re: expansion References: <200006150826.KAA05864@beta.informatik.hu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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? > 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? > [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 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. > 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. 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). For styles whose values are arrays, it would be useful to be able to return $value/$reply as an array. 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. 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. Oliver