From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11352 invoked from network); 7 Jun 1999 12:23:57 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Jun 1999 12:23:57 -0000 Received: (qmail 23197 invoked by alias); 7 Jun 1999 12:23:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6500 Received: (qmail 23190 invoked from network); 7 Jun 1999 12:23:41 -0000 Message-Id: <9906071154.AA28129@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: completion in quotes In-Reply-To: "Sven Wischnowsky"'s message of "Mon, 07 Jun 1999 12:54:36 DFT." <199906071054.MAA06674@beta.informatik.hu-berlin.de> Date: Mon, 07 Jun 1999 13:54:51 +0200 From: Peter Stephenson Sven Wischnowsky wrote: > This makes completion always work on whole quoted strings. It has the > special casing for string that start with a quote as discussed last > week. The code is very careful to change the word as few as possible, > I hope it is even better than what Bart suggested in 6471. Wow. It looks like the compsys.yo chunk was just a repeat of the documentation for $compcontext, and there was some debugging code in _brace_parameter so it needed applying by hand, but I think it was all unambiguous. > 1) The code tries to automatically insert closing quotes. This is also > done during menucompletion -- is this ok? Maybe in principle this should be compstate-able, but I won't worry too much. > 2) `compset -q' currently does nothing if the current word isn't > quoted. This could be changed to always split the current word at > spaces even if not inside quotes. Should we? I'd say, not until there's a clear use for this, then (presumably) you can share code in cases which do or don't have quotes. The spaces to split on in this case would have to have been put there explcitly by the completion code, wouldn't they? Otherwise they'd have to be quoted already to get that far. Or are you distinguishing between "zsh -c 'echo foo'" and "zsh -c echo\ foo"? Ideally those two should be split in the same way. > 3) The code tries hard to correctly close quotes inside parameter > expansions. While writing this is saw again that ${'$a'} is the > same as $$. Shouldn't we disallow single quotes there? > At least the completion code can only handle double quotes. Ideally, yes, if they don't work. Most shells test give a `bad substitution' message which suggests they test it in the equivalent of parmsubst(). It could be hard to work out where it's necessary then. > 4) I changed `_brace_parameters' to automatically insert closing > quotes inside parameter expansions (`${"foo'). This fails with > completeinword if there already was a closing quote on the line. > I may have to rethink something here. Maybe this should always be > done automatically without the completion widget having to bother > about it. Probably in a way that closes the expansion automatically > only if there is no user-supplied -S suffix. It could get quite icky if you're trying to close nested things all the time. Anything simple and consistent would be OK. > 5) The `_closequotes' completer should be superfluous now. I was about to ask. I'll delete it in the next version (and the documentation). I won't bother sending a patch. > Ok. Now I beg everyone who ever complained about the handling of > quotes in completion to test all this and send us comments, > suggestions, and so on. Please. Yes? I'll try and get pws-21 out by tomorrow, after I've dealt with Andrej's comments on installing functions. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy