From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8131 invoked from network); 6 Nov 1998 19:06:32 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 6 Nov 1998 19:06:32 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id OAA28940; Fri, 6 Nov 1998 14:04:00 -0500 (EST) Resent-Date: Fri, 6 Nov 1998 14:04:00 -0500 (EST) From: "Bart Schaefer" Message-Id: <981106110224.ZM3263@candle.brasslantern.com> Date: Fri, 6 Nov 1998 11:02:24 -0800 References: <199811021036.LAA22116@beta.informatik.hu-berlin.de> <199811021129.LAA11861@diamond.tao.co.uk> <199811021200.NAA22140@beta.informatik.hu-berlin.de> <199811021231.MAA12204@diamond.tao.co.uk> <199811021348.OAA22695@beta.informatik.hu-berlin.de> <199811031558.QAA28492@beta.informatik.hu-berlin.de> In-Reply-To: <199811031558.QAA28492@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "new completion behaviour version 2" (Nov 3, 4:58pm) X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@math.gatech.edu Subject: Re: new completion behaviour version 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"cmjun.0.747.WWqGs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4585 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Finally catching up on this part, too ... there's a bit of skipping around in the following because I don't want to rehash things that were already discussed, such as using an associative array instead of a "compfunc" command. On Nov 2, 11:36am, Sven Wischnowsky wrote: } Subject: completion behaviour (was: zsh-workers: zsh-3.1.5 released) } } We use zle widgets, probably a new kind of widgets that uses some more } special variables, like: } } CMDSTR - the name of the current command, with some special values } it could be used for certain contexts (conditions, math } expressions, ...) } words - the words of the current command (an array) } CURWORD - the number of the current word (for words[CURWORD]) } PREFIX - the prefix of the current word } SUFFIX - ... } NMATCHES - the number of matches produced so far If we're going to add associative arrays anyway (which I take it would just be some kind of parameter syntax for frobbing a hash table) then I'd just as soon have the set of scalars (CMDSTR, CURWORD, etc.) be in such an associative array. As for the words of the current command ... I'm thinking I'd like them to come in as the positional parameters. We already have syntax for altering the $* array (shift, set, and 3=foo among other things); it should be possible to recapture the contents after the function exits; and it is an extremely intuitive way to refer to the command line. (You can almost do this today by using read -Ac argv ; shift in a compctl -K function, except that stomps the $1/$2 prefix/suffix.) } For producing the actual matches there is another builtin, say } `compadd'. [...] } with a different way to handle control flags (-U, -q, } grouping,...). We could make these flags be used `from now on' and } probably have a way to save/restore the current set of control flags } (whose state would be stored together with the matches produced), } e.g. (in an easy-to-read syntax): } } compadd -push } compadd -quote -suffix '/' } compadd -files # optional glob pattern here } ... } compadd -pop The main problem I have with this is that it's too easy to forget the "pop". If you want to do something of this sort, it really needs its own syntax. One way to accomplish that without having to muck about with the zsh parser is to supply ONLY the "push" version of the command, but define it to extend exactly to the end of the current function, as for "local" variables and "setopt localoptions". The user can control scope by defining functions that call one another. } I.e. use the normal shell tests and the special variables. But there } is a problem with this: with compctl the `-x' - tests not only test } for a certain condition, but also report some information back, } namely: the length of an prefix that should be ignored in the } completion string and (with `r[a,b]') a restriction on the command } words that should be used with `compctl -L'. Pardon my density, but I don't follow the connection between r[a,b] and `compctl -L'. Do you mean `compctl -l'? } complist -k } complist -c Incidentally, with respect to menu completion, I don't think the widget should get involved directly in cycling through the menu choices. (I can easily be convinced otherwise, but right now I don't see a compelling argument.) Once the the control flags have indicated that you have a menu of choices, don't invoke the widget again until the prefix changes. That is, the widget can say "here are the completions, and here is where you insert them" but then let hardwired code take over cycling through the menu if there are multiple matches. } `complist' should also offer ways to access some more information, } especially we need a way to decide if the recexact and listambiguous } behaviour should be emulated. Recexact can be emulated entirely by the wiget by simply producing only a single match. Listambiguous can be a flag attached to the generated list of matches, can it not? } Finally we need a way to make the completion code list the matches } found. This could be done with `complist' or by using the return code } of the completion widget. I do think the return code should be meaningful, but only in a success/ failure sense like any other shell function; e.g. if the widget returns nonzero and there are no other functions left to try, then feep). On Nov 2, 11:29am, Zefram wrote: } Subject: Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released) } } >For producing the actual matches there is another builtin, say } >`compadd'. } } OTOH, I think this perhaps should be split into two builtins. One to } add sets of matches in a manner based on the compctl syntax (this could } even be part of the compctl module, and use the compctl code to handle } *all* the compctl options). Another, more basic builtin would merely } provide an interface for adding a single match (or a set of matches), } with options to separately control each part of the match structure. What I had in mind a while back was an interface to add one or more matches with options for the controls associated with that collection of matches; plus interfaces (possibly commands, possibly variables) to obtain the information that's currently only available to compctl and pass it to the add-matches interface. So for example there would be a command or an array variable that gives the names of all the disabled commands, and you'd do compadd $disabled instead of compadd -dFB (That's probably not the best example, but just to give the idea.) } >is a problem with this: with compctl the `-x' - tests not only test } >for a certain condition, but also report some information back, } >namely: the length of an prefix that should be ignored in the } >completion string } } This should be part of the match structure, and the user should be able } to control it explicitly. I agree that the user should be able to control it, but it may be easier for the completion code to compute a default. Expose power you can use if you want it, but don't require that you use it. On Nov 2, 1:00pm, Sven Wischnowsky wrote: } Subject: Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released) } } Partly agreed (see above), but I would still like to give the user } some more support. Think of `r[-exec,;]'. The user would have to do the } matching and before (s)he can produce matches (s)he would have to tell } the completion code which command words should not be used. This can } get a bit nasty. I agree, and I liked your comptest idea. For example, something like if comptest index -1 / ; then to mean what n[-1,/] accomplishes now. (There could even be a flag in [[ ]] to mean "test completions", e.g., [[ -C index -1 / ]] for the above.) The issue I see is with keeping the results sane should the user change CURWORD (or whatever represents it). But that's no more serious than answering the question "where do I zle-insert this match if the widget has repositioned the cursor?" On Nov 2, 12:31pm, Zefram wrote: } Subject: Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released) } } What you need there is for the user-defined completion function, after } recognising the "-exec", to recursively invoke the completion mechanism } on the restricted range of words. As long as completion can be invoked } recursively, there's no need for more specific support for this type } of construct. (Consider also how to properly handle completion of the } word after "sh -c".) Recursively invoking completion functions is a good idea, and IMNSHO is the best argument that I can think of for passing the command words as the positional parameters. (There is of course still the issue of $0, but that's not too terrible. Just assign to CMDSTR or whatever takes its place in the associative array, before calling the other function.) On Nov 3, 4:58pm, Sven Wischnowsky wrote: } Subject: new completion behaviour version 2 } } The coding scheme for xor'ed completion is trivial. The code for `-x' } stuff will be done using `if'-tests with the information stored in } local variables. We then need a way to notify the completion code } about two things it will have to use (to be able to do the same things } `-x' can): the length of an ignored prefix of the current word and } (for `-L') which part of the words-array should be taken as command } words. I still think you must mean `-l' there. Un-confuse me, please. } To be } able to correctly save/restore this type of information we will need a } way to get the current state in a way that can be used to restore it } later Once again I suggest using function scope; save and restore like local variables and setopts. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com