zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: ignore-line style
Date: Fri, 19 Oct 2001 17:50:15 +0100	[thread overview]
Message-ID: <3BD059C7.31724D13@yahoo.co.uk> (raw)
In-Reply-To: <15311.62071.434241.26495@gargle.gargle.HOWL>

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


      reply	other threads:[~2001-10-19 16:57 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
2001-10-19 16:50         ` Oliver Kiddle [this message]

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=3BD059C7.31724D13@yahoo.co.uk \
    --to=okiddle@yahoo.co.uk \
    --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).