ignore-line style

ignore-line style

[Oliver Kiddle]

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.

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.

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.

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.

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.

Any thoughts or ideas?

Oliver

--- Completion/Base/Core/_description     Tue May  8 10:12:50 2001
+++ _description        Tue Oct  9 15:38:53 2001
@@ -38,6 +38,7 @@
   zstyle -s ":completion:${curcontext}:$1" ignore-line hidden &&
     case "$hidden" in
     true|yes|on|1) _comp_ignore=( "$_comp_ignore[@]" "$words[@]" );;
+    full-word) _comp_ignore=( "$_comp_ignore[@]" "${(M)words[@]:#$PREFIX*$SUFFIX}" );;
     current)       _comp_ignore=( "$_comp_ignore[@]" "$words[CURRENT]" );;
     current-shown) [[ "$compstate[old_list]" = *shown* ]] &&
                        _comp_ignore=( "$_comp_ignore[@]" "$words[CURRENT]" );;

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: ignore-line style

[Sven Wischnowsky]

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

Re: ignore-line style

[Nadav Har'El]

> Oliver Kiddle wrote:
> > 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.

By the way, most modern diffs (GNU, solaris, etc.) allow you to do
	diff file ../
as a shortcut to
	diff file ../file

So you never actually need to complete that second file to the same basename...
I do agree it's a bit weird, though.

-- 
Nadav Har'El                        |      Monday, Oct 15 2001, 28 Tishri 5762
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |A city is a large community where people
http://nadav.harel.org.il           |are lonesome together.

Re: ignore-line style

[Sven Wischnowsky]

I wrote:

> 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.

Here is what seems to fix it. It was using _comp_ignore on every level 
it walked through, hence `file' matched.

This seems almost too simple to not have any other effects, but let's
try... (I'll leave it to Oliver to commit his patch).


Bye
  Sven

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.13
diff -u -r1.13 _path_files
--- Completion/Unix/Type/_path_files	2001/10/11 09:19:56	1.13
+++ Completion/Unix/Type/_path_files	2001/10/17 13:23:54
@@ -351,19 +351,19 @@
       elif [[ "$tmp1[1]" = */* ]]; then
         if [[ -n "$_comp_correct" ]]; then
           tmp2=( "$tmp1[@]" )
-          builtin compadd -D tmp1 -F _comp_ignore "$matcher[@]" - "${(@)tmp1:t}"
+          builtin compadd -D tmp1 "$matcher[@]" - "${(@)tmp1:t}"
 
           if [[ $#tmp1 -eq 0 ]]; then
             tmp1=( "$tmp2[@]" )
-	    compadd -D tmp1 -F _comp_ignore "$matcher[@]" - "${(@)tmp2:t}"
+	    compadd -D tmp1 "$matcher[@]" - "${(@)tmp2:t}"
           fi
         else
           tmp2=( "$tmp1[@]" )
-          compadd -D tmp1 -F _comp_ignore "$matcher[@]" - "${(@)tmp1:t}"
+          compadd -D tmp1 "$matcher[@]" - "${(@)tmp1:t}"
         fi
       else
         tmp2=( '' )
-        compadd -D tmp1 -F _comp_ignore "$matcher[@]" -a tmp1
+        compadd -D tmp1 "$matcher[@]" -a tmp1
       fi
 
       # If no file matches, save the expanded path and continue with

-- 
Sven Wischnowsky                    wischnow@informatik.hu-berlin.de

Re: ignore-line style

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> Here is what seems to fix it. It was using _comp_ignore on every level
> it walked through, hence `file' matched.
> 
> This seems almost too simple to not have any other effects, but let's
> try... (I'll leave it to Oliver to commit his patch).

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.

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. 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?

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?

Thanks again

Oliver

Re: ignore-line style

[Sven Wischnowsky]

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

Re: ignore-line style

[Oliver Kiddle]

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