From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12594 invoked from network); 7 Jun 1999 12:42:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Jun 1999 12:42:48 -0000 Received: (qmail 25198 invoked by alias); 7 Jun 1999 12:42:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6501 Received: (qmail 25191 invoked from network); 7 Jun 1999 12:42:41 -0000 Date: Mon, 7 Jun 1999 14:42:36 +0200 (MET DST) Message-Id: <199906071242.OAA07060@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Mon, 07 Jun 1999 13:54:51 +0200 Subject: Re: PATCH: completion in quotes Peter Stephenson wrote: > 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. Ugh. Sorry. > > 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. Hadn't thought of that... but I'll first let it sink in anyway. > > 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. (I take the double quotes as being meta-characters in this case.) This is the thing I was thinking about. Here, `compset -q' will only return true (and modify the parameters) in the first case, not in the second one, because the code knows that there is/isn't a single quote at the beginning. > > 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. Btw. When the code automatically inserts closing quotes, this is only done for one level. If you use `compctl -h' or `compset -q' to complete parts of: % foo 'bar "baz the code inserts only the ", not "', and only if there is no other suffix worth inserting. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de