Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: ignore-line style
- X-seq: zsh-workers 16087
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: ignore-line style
- Date: Fri, 19 Oct 2001 17:50:15 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <3BC31D30.11F61508@xxxxxxxxxxx> <15306.60590.817177.439249@xxxxxxxxxxxxxxxxxx> <15309.34622.18416.249769@xxxxxxxxxxxxxxxxxx> <3BCF0416.D4BA1B79@xxxxxxxxxxx> <15311.62071.434241.26495@xxxxxxxxxxxxxxxxxx>
- Sender: kiddleo@xxxxxxxxxxxxxxxx
Sven Wischnowsky wrote:
>
> I was fearing problems with the ignore-parents style, but all the
> things I tried worked as before.
I can't find any problems there either.
> > If this constitutes having got it working better as you said in you
> > first reply then I'd like to look at adding some of the suggestions I
> > made.
>
> Yep, I think. We should probably make that depend on another style
> anyway (one that default to true -- ignore-same or something better).
Sorry, what should this ignore-same be used for?
> > For the styles, that was quoting to avoid globs, file like globs,
> > skipping command words and skipping options. To achieve file like
> > globs, one way would be to eval the words (something similar to
> > _expand) which would have the advantage of expanding braces and
> > variables too but process substitutions would be a problem. Have you
> > got any other ideas or suggestions?
>
> Only what I think you are thinking about anyway: making some of the
> new values modifiers, e.g.:
>
> zstyle '...' ignore-line other quote
>
> where `quote' is a modifier `working on' `other'.
Yes. I'd be tempted to suggest that existing values be made modifiers so
by default it would ignore all other words except the command and the
modifiers `current' and `command' would be there to ignore those too.
> I'm not sure, either. Probably the cleanest solution would be to give
> _description an option to tell it which ignore-line value should be
> used as the default. But that would need changes in every utility
> function calling _description to pass down that option, which isn't
> nice.
Does every utility already pass down -F? We could encode what we want
in the argument to -F or maybe use a utility function which is called to
construct an appropriate list for the -F argument. The utility function
could either be called from _description in response to the styles or
directly from the commands own completion.
The reason I mention _arguments is that it might be nice if _arguments
could remove options from the list. If you imagine this completion
function:
_arguments -s -S '-r[recursive]' '-f[force]' '-i[interactive]' \
"*:file:_files -F words"
_arguments could see the -F option and remove instances of -r, -f and -i
from the parameter to -F. This might be particularly useful where there
are several types of non-option arguments and we only want to ignore
words which are for the current _arguments spec.
> And using a completion-system-global parameter to pass this
> information to _description isn't clean either.
Yes, that wouldn't be nice. I'll try to think of other options.
And thanks for fixing the _conditions thing.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author