Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: selective parameter completion
- X-seq: zsh-workers 12587
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: selective parameter completion
- Date: Fri, 11 Aug 2000 09:44:21 +0200 (MET DST)
- In-reply-to: Oliver Kiddle's message of Thu, 10 Aug 2000 21:06:09 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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.
> 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:
> : $(( <tab>
> 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
Just use _subscript, but make sure everything is set up correctly for
it. For example:
seems to work for the (admittedly simple) cases I tried.
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: