From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.dk
Subject: Re: ignore-line style
Date: Mon, 15 Oct 2001 16:03:26 +0200 [thread overview]
Message-ID: <15306.60590.817177.439249@gargle.gargle.HOWL> (raw)
In-Reply-To: <3BC31D30.11F61508@yahoo.co.uk>
Oliver Kiddle wrote:
> I use this style:
>
> zstyle ':completion:*:*:(cat|diff|less|rm|vi):*' ignore-line true
>
> So, filenames I've already mentioned are not offered for completion
> with these commands. This is useful but there is a problem:
>
> With diff, it is quite common to compare a file to another file with
> the same name in a different directory but this style blocks completion
> of the second file. e.g: diff file ../fi<tab>
> It needs to include the `../' in the comparison against other words on
> the line.
Yeah, I've stumbled over this, too, but didn't have the time to work
on it. And what's even more irritating, for me it shows that `file' in
the list but doesn't complete to it.
> The patch below adds a `full-word' value for ignore-line to show a
> possible fix but I think we need more than this patch. This doesn't
> work if the current line includes words which are patterns for a start.
Right, I hadn't thought about that. (The style was (and still is) very
experimental, it was added in only one or two minutes, without
thinking much about the consequences -- and I always thought I was the
only one using it ;-)
> This change is perhaps needed in conjunction with the `other' value
> too. And it would be useful to be able to ignore the first word (the
> command) as well as the current one.
Or the word before the command (in _precommand).
> Next, there could be an option to use "${(q)words[@]}" to quote
> the words so they aren't used as patterns - useful if the command is
> being used with noglob or with non-file parameters. Otherwise, working
> like a real file glob so *.o doesn't match .o would be nice. And maybe
> a way to define a further pattern which words in _comp_ignore need to
> match so that you can exclude any non-file arguments such as options.
Right.
> I also wonder whether we shouldn't be passing the previous words as a
> -F argument to compadd from _diff & co. in the first place.
But only when we've got it working better...
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next prev parent reply other threads:[~2001-10-15 14:03 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 [this message]
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
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=15306.60590.817177.439249@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).