From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10707 invoked from network); 14 Feb 1999 21:43:33 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Feb 1999 21:43:33 -0000 Received: (qmail 22554 invoked by alias); 14 Feb 1999 21:42:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5376 Received: (qmail 19500 invoked from network); 14 Feb 1999 21:27:20 -0000 From: "Bart Schaefer" Message-Id: <990214132609.ZM29109@candle.brasslantern.com> Date: Sun, 14 Feb 1999 13:26:09 -0800 In-Reply-To: <199902141154.LAA13108@Indigo.thoth.u-net.com> Comments: In reply to opk@thoth.u-net.com (Oliver Kiddle) "Re: Completion suggestions" (Feb 14, 11:54am) References: <199902141154.LAA13108@Indigo.thoth.u-net.com> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@sunsite.auc.dk Subject: Re: Completion suggestions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 14, 11:54am, Oliver Kiddle wrote: } Subject: Re: Completion suggestions } } I've made a couple of observations on differences between zsh and tcsh's } completion behaviour: } ~ [68]% :> "a file" } ~ [69]% less "a } tcsh completes to: } ~ [69]% less "a file" _ } whereas zsh completes to: } ~ [69]% less "a file _ } where the underscore is the cursor. I prefer tcsh's behaviour in this } case. It's possible that quote handling could be made more context-sensitive. In the absence of such sensitivity, I'd rather it behaved as it does now, because with ordinary completion you never need the quotes: zsh% less a produces: zsh% less a\ file ^ cursor here I made up this little function: __test() { for i in CONTEXT COMMAND IPREFIX PREFIX SUFFIX CURRENT argv typeset $i } Then bound it with zle -C and bindkey and tried your example above. The result, which of course scribbles all over the command line, is: CONTEXT=argument COMMAND=less IPREFIX='' PREFIX='' SUFFIX='' CURRENT=1 argv=(a) Thus note that the quotes are gone by the time the completion code gets a crack at the argument words. This happens because zsh uses the parser to scan the command line and determine the context. In a new completion function, however, we can also get at the LBUFFER and RBUFFER, so we could look both ways to see if we're inside already closed quotes (for completeinword) or are working on an open quote, and try to fix it up. However, it's really difficult -- particularly in multi-line commands -- to decide whether you're inside an open quote. For example, in zsh% ls ' quote> "a the value of LBUFFER is only the line at the secondary "quote> " prompt. You can't tell that you're inside two different sets of open quotes by looking at any of the variables (and of course the second quote isn't really "open" because it's inside the first quote and therefore has no syntactic significance). } While quotes are open, spaces within the quotes separate words [...] } But when quotes are closed, a quoted area is all one word. [...] } It is difficult to say what the best thing to do is. I think zsh is } wrong because it is inconsistent but admit that it is more flexible than } tcsh because there is control of words within quotes. I don't think I've } needed this control in any of my compctls so would be in favour of } removing the inconsistency. Because, as I mentioned above, I never type the quotes at all unless I mean for them to quote multiple words, I typically use this "inconsistent" behaviour in ALL my completions that involve quoting. Never having used tcsh, I never had any reason to expect any other behavior. } Maybe what is needed is some way of } referencing words within quotes. You first have to figure out that the words are within quotes; see the multiline remarks above. Tcsh doesn't have to deal with that, because csh quotes may not be unmatched across multiple input lines. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com