From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23015 invoked from network); 22 May 2000 08:39:10 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 22 May 2000 08:39:10 -0000 Received: (qmail 16012 invoked by alias); 22 May 2000 08:38:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11486 Received: (qmail 15997 invoked from network); 22 May 2000 08:38:14 -0000 Date: Mon, 22 May 2000 10:37:00 +0200 (MET DST) Message-Id: <200005220837.KAA09906@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Oliver Kiddle's message of Fri, 19 May 2000 19:39:23 +0100 Subject: Re: PATCH: Re: _netscape Oliver Kiddle wrote: > ... > > I've gone on to try to fix the handling of the closing bracket suffix in > netscape remote commands which has resulted in the following thoughts on > suffix handling in the new completion. > > There are a few places where the contents of a remote command comes to a > definite finish: a file/ftp/http URL that ends with a file or empty > directory, a saveAs command after the file type, about: URLS. In these > cases, it would be nice if completing the last stage added both the > closing bracket (back-slash quoted if necessary) to terminate the remote > command and any closing quote. > > Adding a closing quote sometimes happens, for example: > netscape -remote 'openURL(about:c > this completes to the about:cache URL with the closing quote appended. > Where does the quote come from: is the default suffix actually > "$compstate[quote] " instead of just a space? Approximately, yes. If the completion code thinks or knows that there has to be a certain closing quote (or closing quotes) and there is no other suffix, the quote is inserted. This was added at the last completion-in-quotes overhaul (and in most cases gives one automatically what one wants). > ... > > Basically, what a helper function needs to do is > take the suffix passed to it and when it is completing a final component > of itself, it should pass any suffix it wants with the one passed to it > appended. Pulling out -S options from "$@" is going to look messy > without some special handling at a lower level somewhere. It's mostly a bit of [(i)...] stuff, but yes, it's probably common enough... One idea would be to add an option to zparseopts to allow it to extract options. Actually, I've been wishing for something like that, too. > compadd seems > to only use the first -S option it is passed but this isn't documented > so I didn't want to rely on it. It *is* documented, in the compadd entry, below the options. _approximate always relied on it. > If we do make it a documented feature > then we still need to handle the situation where you are completing the > final part of something and you want to use both your own suffix and the > one passed to the function. One problem I see here is that in some cases utility functions might want to use their suffix only as a default, overridden by the one given by a calling function (easy to solve). Another problem might be the interaction with -[qrR]. > Note that _files can no longer complete subdirectories if you give it a > -S option which is something other than a slash. _files should only add > the suffix after a file (and possible after an empty directory). Sometimes you want it, sometimes not... > Returning to _netscape, the next issue was how to handle the closing > bracket/quote already being there. > I used compset -S '(|\\)\)*'. But this again comes up with a problem > when we are not completing the final part of a URL. The suffix is only > moved to ISUFFIX so for example: > netscape -remote 'openURL(a) i.e. cursor is at position of tab > will complete the url to about:)' - advancing the cursor past the > suffix. I'm able to prevent this by not using the suffix with compadd > if the compset succeeded. You may also want to have a look at $compstate[to_end]... > This example shows how and leads me on to my next point: > > _foo() { > local lsuf="" nsuf="" > compset -S '.*' || lsuf=". " > if compset -P "*:"; then > compadd -S "$lsuf" aaa bbb ccc > else > compset -S ':*' || nsuf=":" > compadd -S "$rsuf" one two three > fi > } > > foo o. completes the one but moves the cursor past the '.'. I > would prefer if it was only moved to the end of the :. We started off > with just 'o.' so there was no :. this indicates to me that the part > which comes after a colon is necessary so it is likely that the user > will want to complete it. In the case of: > foo o:ddd. > it is fair enough in a way that the completion moves past the final '.' > because there was a colon there to start with although even in this case > I'd prefer it didn't. What I would actually want it to do in this case > is move to the end of the 'ddd' but before the '.'. If 'ddd' was > incomplete, I could finish it otherwise, another tab would advance me on > to the next thing. This, of course can't be solved even by to_end. The way suffixes are handled has mostly historical reasons and, yes, it is a bit simple minded. If someone wants to help to improve it, I'd like to have a short and comprehensive list of things one might want to do, so that we can discuss it easliy and find the (hopefully few) basic things we need for that. With that we could then think about changing the code. Ok? (I don't think I'll have much time to think about this...) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de