From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4331 invoked from network); 11 Aug 2000 07:45:08 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Aug 2000 07:45:08 -0000 Received: (qmail 15423 invoked by alias); 11 Aug 2000 07:44:26 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12587 Received: (qmail 15416 invoked from network); 11 Aug 2000 07:44:24 -0000 Date: Fri, 11 Aug 2000 09:44:21 +0200 (MET DST) Message-Id: <200008110744.JAA09800@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Oliver Kiddle's message of Thu, 10 Aug 2000 21:06:09 +0100 Subject: Re: PATCH: selective parameter completion Oliver Kiddle wrote: > I've implemented the change to _parameters which I mentioned yesterday > and modified a few other completion functions to make use of it. Great. > In the > process, it has raised a few questions: > > In _arrays, _wanted is used but _parameters also calls _wanted so the > description of what is to be completed - 'array' - is replaced by > 'parameter'. _files manages to avoid this problem so how is it done and > what should _parameters be doing here? I think none of the functions calling _parameters should be calling _wanted (when calling _parameters). For files, the tag comes with the file-patterns style, so we'll have them for _parameters once we add a parameter-patterns (or should it be parameter-types?) style. For other cases, _files (and _path_files) looks at the pattern to find out if it is completing directories. For now, I think using only the parameter tag is fine (and adding a special option, like the -/ for _files, to make it complete only, say, arrays, is probably not worth it). But _parameters should take care to make a description supplied by the calling function take precedence over its own description -- just as _files does it. (For this and the pattern stuff we could probably just copy some code from _files...) One question that might be interesting is (already asked by you in your last mail for this), if there are cases where making the default completion try different types of parameters one after another makes sense (as in file completion). The only and obvious case I can think of is when the calling function uses -g. I.e. first try it with that pattern and the complete all parameters. > How does the implementation of _math differ from if compset -P and > compset -S were used to move the patterns from PREFIX to IPREFIX and > SUFFIX to ISUFFIX? It would be nice if spaces were treated more > cleanly, for example: > : $(( > doesn't complete parameters but quotes the space. Hm, it does complete parameters for me (and only integers and floats). But the quoting is... urgh. Another thing is that _math should not complete the special-character parameters (like !, $, etc.) and that it should use parameter-expansion completion after a `$' inside a math expression. The latter has to be fixed in C code, I'll have a look. And the quoting has to be fixed in C-code, too, I think, because the space is already reported in quoted form, which it shouldn't when completing in a math expression. > I have made _vars complete arrays and associations separately so that a > '[' suffix can be added automatically. The trouble here is that it has > to be quoted unless the glob option is not set otherwise a message > about no matches being found will be printed when the command is run. > Is it worth checking the state of the glob option before quoting this > suffix. If so, should _precommand be doing a 'setopt localoptions > noglob' when the noglob command is being completed to ensure the option > is set during the completion of the command after it? Except for command position, I think we should just always quote it (using compquote to get it right without having to test if we are in single or double quotes ourselves). > Also, it would make sense to use _vars instead of _parameters when > completing in command position but the square brackets aren't treated > as a pattern there so how can I detect that it is being used in command > postion: is [[ CURRENT = 1 ]] going to work? Yes, it should. > As far as I can tell, the existing code in _vars for completing > association keys after an opening square-bracket is only useful when we > have quoting because _subscript will do the job otherwise. I would add > similar code for array indexes but it seems a bit pointless to be > repeating code that we already have in _subscript. Calling _subscript > doesn't seem to work so what would be a good way to avoid this > repetition? Just use _subscript, but make sure everything is set up correctly for it. For example: compstate[parameter]=${PREFIX%%(|\\)\[*} IPREFIX=${PREFIX%%\[*}\[ PREFIX=${PREFIX#*\[} _subscript seems to work for the (admittedly simple) cases I tried. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de