From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.dk
Subject: Re: ignore-line style
Date: Fri, 19 Oct 2001 11:29:27 +0200 [thread overview]
Message-ID: <15311.62071.434241.26495@gargle.gargle.HOWL> (raw)
In-Reply-To: <3BCF0416.D4BA1B79@yahoo.co.uk>
Oliver Kiddle wrote:
> ...
>
> As far as I can tell, this works very well. I've included testing of
> this mixed with the ignored-patterns style and all seems well. The
> explanation makes sense so hopefully there are no "other effects".
> Thanks.
I was fearing problems with the ignore-parents style, but all the
things I tried worked as before.
> 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).
> 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'.
> The other suggestion was modifying _diff etc to set up the ignoring
> without the need for a style. Can that be done better at the _files or
> _arguments level at all? For what situations do you use the style and
> can anyone think of any other commands where this ignoring could be
> useful?
Damn, I hoped you had an idea, ready to be implemented ;-)
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.
And using a completion-system-global parameter to pass this
information to _description isn't clean either.
Hm.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next prev parent reply other threads:[~2001-10-19 9:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 15:52 Oliver Kiddle
2001-10-15 14:03 ` Sven Wischnowsky
2001-10-15 15:12 ` Nadav Har'El
2001-10-17 13:27 ` Sven Wischnowsky
2001-10-18 16:32 ` Oliver Kiddle
2001-10-19 9:29 ` Sven Wischnowsky [this message]
2001-10-19 16:50 ` Oliver Kiddle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15311.62071.434241.26495@gargle.gargle.HOWL \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).