Re: ignore-line style

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx