From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20514 invoked from network); 1 Jun 1999 10:37:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Jun 1999 10:37:47 -0000 Received: (qmail 17692 invoked by alias); 1 Jun 1999 10:37:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6417 Received: (qmail 17685 invoked from network); 1 Jun 1999 10:37:23 -0000 Date: Tue, 1 Jun 1999 12:37:18 +0200 (MET DST) Message-Id: <199906011037.MAA19904@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Mon, 31 May 1999 23:21:03 +0000 Subject: Re: Better completion in quotes Just a couple of comments, as far as I was able to think until now, collecting suggestions made by others... Personally, I would prefer a solution where we always return the whole quoted string (so that the default behavior is the same as in bash/tcsh) and we have a flag very much like -l which says that the word we are currently working on should be split into separate words and completion should then continue on these. The first question is if we should use the lexer to split it and then use all the information we can get from it or not. In some cases this may be good to have (if the string contains shell code we could get better context information -- if we are in a [[..]]] and things like that). But in some cases this may not be what we want, so maybe we should just split the string at spaces (and try to do this right with nested quotes). This would also make it look more like -l, because that doesn't recognise shell constructs, either. The great problem with this is that this is something completely new to the completion code. Currently we only have one set of words and the string, they can be handled independently in most cases. With such a string-splitting, we would have to temporarily (completely) change the array of waords and we would have to remember where to insert the completion for each match because matches may be produced for the whole string and a part of it. Currently we only save the positions of the whole string and replace the original with whatever was completed. This gets worse when thinking about the new completion stuff. I suggested an option to compadd that sets the special parameters to make them work on the parts of the current word. But we would have to preserve information about the original string internally to be able to insert matches for the whole string and parts of it. And in the new completion code, the user can set the parameters to anything he likes and thus the internally stored information about whether we are working on the whole string or a part of it can be garbled. We could make it accessible to the user, but how? Another set of `ignored' prefix/suffix? Note also that with this solution the new flag has no effect on the surrounding flags, but one can always do the same trick as with -l, using a dummy compctl: compctl -1 _files foo compctl -f _files Which may be a bit ugly. I haven't thought much about making it work on the other flags, being rather fixed on the `like -l' thing. And, btw., the fact that the lexer knows about the quoting state (as Peter mentioned) doens't help us here because the completion code gets information only about whole strings and I don't want it to be called on every quote or something like that. It would make get_comp_string() even more complicated. Ok. Some of these things may be simpler to solve than I can see now, I'll try to hack something soon, but don't hold your breath. (And of course, others may want to give it a try, too.) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de