From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19753 invoked from network); 27 May 1999 11:10:51 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 May 1999 11:10:51 -0000 Received: (qmail 28742 invoked by alias); 27 May 1999 11:10:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6357 Received: (qmail 28735 invoked from network); 27 May 1999 11:10:35 -0000 Date: Thu, 27 May 1999 13:10:32 +0200 (MET DST) Message-Id: <199905271110.NAA10649@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 27 May 1999 09:34:49 +0000 Subject: Re: Some possible bugs... Bart Schaefer wrote: > } The problem is that in things like `zsh -c "ls ' one doesn't want > } the shell to treat the `"ls ' as one string. So when completing inside > } quotes, zsh treats words separated by spaces as outside the quotes. > > How hard would it be to make this context-sensitive? Well, currently this is done by get_comp_string() which calls the lexer and this *has* to be done at the very beginning, because we first have to get the command line words and position to find out which compctl to use. However, we could remove all this quote-removal stuff and make it always just return the whole quoted string. > For example, when > the effective compctl says to complete file names, treat the entire > quoted string as one word and attempt to complete it as a file (this is > what bash appears to do); similary for command names or anything else > that normally results in a single shell "word"; otherwise, complete the > way it's presently done. This might require another compctl option, > similar to using compctl -x ... -l '' ... except that the > "range of command line words that are considered to be arguments" is a > single word that has to be split at IFS before completing. I think this wouldn't be enough. One example is the: % zsh -c "ls 'foo b I mentioned. This should complete to 'foo bar' if there is such a possible match. So we would need a way to `remove one level of quotes'. But the quotes may also contain things where we would need the whole lexing/parsing if we suddenly decide to work on the parts of the quoted string. And, of course, such a quoted string may contain other quoted parts on which we may or may not want to work separately. > So to get the current behavior you'd use something like (writing old style) > > compctl -x 'c[-1,-c]' -1 -l '' -- zsh > > where I'm using -1 as this new option I've described for no better reason > than that I can't remember which (if any) letters are left for compctl. (The only free letter is `h'). > This would also mean that, in the case where a single word such as a file > name is expected to result, zsh could automatically close the quotes and > append a space after the closing quote. Sure, yes. Enhancing cmatch a bit... > This so-called -1 option could apply to any other flag that followed it, > not just -l ... generically, it would mean "unquote and split the current > word, find a new current word after the split, then complete using the > following flags, and finally requote the result." If we really want `all flags *following* it' we would have to change the argument parsing of compctl, which is already pretty complicated. If we just let it work on all flags surrounding it, at least the parsing would be simple (of course). I confess that I hadn't thought about a flag that `works like -l' (without trying to implement it I would prefer to make it work like -l in that it doesn't have an effect on the surrounding flags -- I think this would be much easier to implement, but I may be wrong). This sounds good to me, with that we could even use the lexing code (calling it on the string we should work on). However, if this gets mixed with completions for the whole quoted string, keeping track of the positions (where to re-insert the completed string, etc.) may turn out to be complicated. Hm, using the quote-removal code when handling this flag and not using the lexer may be easier, but wouldn't allow us to complete at places like `zsh -c "[[ -o '. For the new completion system we would need a way, too. We could use something I've been thinking about when we were discussing it at the beginning. We could give an option to compset which gets one string as argument, parses it and stores the result in $words, $compstate, $IPREFIX, and so on. Bye Sven P.S.: I'm mainly thinking about ways to implement this, so some of my remarks may be hard to understand, sorry. -- Sven Wischnowsky wischnow@informatik.hu-berlin.de