Matching against file suffix

Matching against file suffix

[Andrej Borsenkow]

So far, the two major uses I had for globbing were:

1. patch < /.../zsh/patches/<1234->TAB

This is nice for manually applying patches; I save them with article number and simply get
the next by incrementing number and hitting TAB

2. foo .../zsh/Doc/*.texi

That is the case, when I do know file suffix and want to get just this one file.
Unfortunately, as was oft seen, this has problems with _path_files - and, Sven, you once
wrote, that you do not use globbing at all but use spiffy match controls instead.

Is it possible to match by file suffix with matching control? It is 'course possible by
moving cursor before suffix - but that I'd like to avoid. The idea is to hit TAB at the
end of input word and still get completion.

-andrej

Have a nice DOS!
B >>

RE: Matching against file suffix

[Sven Wischnowsky]

[ the last of my weekend patches ;-]

Andrej Borsenkow wrote:

> ...
> 
> > Or maybe you want to have a way to switch from one type of matches to
> > the `next'.
> 
> Yes. Intent was to see "the most probable" matches first to keep list small, but still be
> able to select more general ones.
> 
> Setting tag "in one string" completes both, but it also lists both.

Here is my first attempt at this... the _next_tags bindable command
(and completer).

Normally it is bound to ^Xn, but to make it really work, _next_tags
should also be included as the (first) entry in your completer list.

Then it should be possible, to hit ^Xn (directly) after you have tried 
completion to get at the next set of tags (and the next and the next
and... with wrap-around). The matches for the new set will be shown
and then you can just hit tab to complete from that set.

Again, I haven't tested it too much, especially with things like
menu-completion.

There are also things we might want to make configurable. For example, 
currently it keeps the restricted set of tags even we you edit the
word we are on (i.e. after you hit ^Xn you can backspace, insert,
etc. and hitting TAB will still complete from the set of matches
selected with ^Xn). This is also connected to the test used to find
out when to stop using the restricted set -- maybe that needs to be
improved.

Bye
 Sven

P.S.: This also contains the .distfiles change for zrecompile. Sorry,
      forgot it again.

diff -ru ../z.old/Completion/Commands/.distfiles Completion/Commands/.distfiles
--- ../z.old/Completion/Commands/.distfiles	Mon Mar 13 11:02:23 2000
+++ Completion/Commands/.distfiles	Mon Mar 13 11:12:28 2000
@@ -2,4 +2,5 @@
     .distfiles
     _bash_completions _correct_filename _correct_word _expand_word 
     _history_complete_word _read_comp _most_recent_file _complete_help
+    _next_tags
 '
diff -ru ../z.old/Completion/Commands/_next_tags Completion/Commands/_next_tags
--- ../z.old/Completion/Commands/_next_tags	Mon Mar 13 11:04:04 2000
+++ Completion/Commands/_next_tags	Mon Mar 13 11:04:17 2000
@@ -0,0 +1,70 @@
+#compdef -k complete-word \C-xn
+
+# Main widget/completer.
+
+_next_tags() {
+
+  if [[ $#funcstack -gt 1 ]]; then
+
+    # Called as completer, probably `remove' our helper function. A better
+    # test would be nice, but I think one should still be able to edit the
+    # current word between attempts to complete it.
+
+    [[ $_next_tags_pre != ${LBUFFER%${PREFIX}} ]] && unset _sort_tags
+
+    return 1
+  else
+    local comp
+
+    if [[ -z $compstate[old_list] ]]; then
+      comp=()
+    else
+      comp=(_next_tags _complete)
+    fi
+
+    (( $+_sort_tags )) || _next_tags_not=
+
+    _sort_tags=_next_tags_sort
+    _next_tags_pre="${LBUFFER%${PREFIX}}"
+    _next_tags_not="$_next_tags_not $_lastcomp[tags]"
+
+    _main_complete "$comp[@]"
+
+    [[ $compstate[insert] = automenu ]] &&
+       compstate[insert]=automenu-unambiguous
+
+    compstate[insert]=''
+    compstate[list]='list force'
+  fi
+}
+
+# Helper function for sorting tags. Most of this is copied from _tags.
+
+_next_tags_sort() {
+  local order tags tag nodef
+
+  zstyle -a ":completion:${curcontext}:" tag-order order ||
+    order=( 'arguments values' options globbed-files directories all-files )
+
+  # But we also remove the tags we've already tried...
+
+  tags=( "${(@)order:#(${(j:|:)~${=_next_tags_not}})}" )
+
+  # ... unless that would remove all offered tags.
+
+  [[ $#tags -ne $#order && "$tags" != *(${(j:|:)~argv})* ]] &&
+    tags=( $order ) _next_tags_not=
+
+  for tag in $tags; do
+    case $tag in
+    -)     nodef=yes;;
+    *\(\)) "${${tag%%[ 	]#\(\)}##[ 	]#}" "$@";;
+    \!*)   comptry "${(@)argv:#(${(j:|:)~${=tag[2,-1]}})}";;
+    ?*)    comptry ${=tag};;
+    esac
+  done
+
+  [[ -z "$nodef" ]] && comptry "$@"
+}
+
+[[ -o kshautoload ]] || _next_tags "$@"
diff -ru ../z.old/Completion/Core/_files Completion/Core/_files
--- ../z.old/Completion/Core/_files	Mon Mar 13 11:02:25 2000
+++ Completion/Core/_files	Mon Mar 13 11:04:14 2000
@@ -33,7 +33,7 @@
     type="${type}/"
   fi
 else
-  dopts=()
+  dopts=(-/)
 fi
 if zstyle -s ":completion:${curcontext}:globbed-files" file-patterns tmp &&
    [[ -n "$tmp" ]]; then
diff -ru ../z.old/Completion/Core/_main_complete Completion/Core/_main_complete
--- ../z.old/Completion/Core/_main_complete	Mon Mar 13 11:02:25 2000
+++ Completion/Core/_main_complete	Mon Mar 13 11:04:17 2000
@@ -21,7 +21,7 @@
 
 local ctxt post ret=1 tmp _compskip format _comp_ignore \
       _completers _completer _completer_num \
-      _matchers _matcher _matcher_num \
+      _matchers _matcher _matcher_num _comp_tags \
       context state line opt_args val_args curcontext="$curcontext" \
       _last_nmatches=-1 _last_menu_style _def_menu_style _menu_style sel \
       _saved_exact="${compstate[exact]}" \
@@ -193,12 +193,13 @@
 comppostfuncs=()
 
 _lastcomp=( "${(@kv)compstate}" )
-_lastcomp[completer]="$comp"
+_lastcomp[completer]="$_completer"
 _lastcomp[prefix]="$PREFIX"
 _lastcomp[suffix]="$SUFFIX"
 _lastcomp[iprefix]="$IPREFIX"
 _lastcomp[isuffix]="$ISUFFIX"
 _lastcomp[qiprefix]="$QIPREFIX"
 _lastcomp[qisuffix]="$QISUFFIX"
+_lastcomp[tags]="$_comp_tags"
 
 return ret
diff -ru ../z.old/Completion/Core/_requested Completion/Core/_requested
--- ../z.old/Completion/Core/_requested	Mon Mar 13 11:02:26 2000
+++ Completion/Core/_requested	Mon Mar 13 11:04:15 2000
@@ -8,7 +8,7 @@
   tag="$1"
 fi
 
-comptags -R "$tag" &&
+comptags -R "$tag" && _comp_tags="$_comp_tags $tag" &&
     if [[ $# -gt 1 ]]; then
       _description "$@"
       return 0
diff -ru ../z.old/Completion/Core/_wanted Completion/Core/_wanted
--- ../z.old/Completion/Core/_wanted	Mon Mar 13 11:02:26 2000
+++ Completion/Core/_wanted	Mon Mar 13 11:04:15 2000
@@ -19,7 +19,8 @@
 fi
 
 if [[ $# -gt 1 ]]; then
-  _tags "$targs[@]" "$tag" && _description "$@"
+  _tags "$targs[@]" "$tag" && _comp_tags="$_comp_tags $tag" &&
+    _description "$@"
 else
-  _tags "$targs[@]" "$tag"
+  _tags "$targs[@]" "$tag" && _comp_tags="$_comp_tags $tag"
 fi
diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Mon Mar 13 11:02:05 2000
+++ Doc/Zsh/compsys.yo	Mon Mar 13 11:04:15 2000
@@ -1861,6 +1861,18 @@
 var(N), complete the var(N)th most recently modified file.  Note the
 completion, if any, is always unique.
 )
+findex(_next_tags (^Xn))
+item(tt(_next_tags (^Xn)))(
+This allows to complete types of matches that are not immediately
+offered because of the setting of the tt(tag-order) style. After a
+normal completion was tried, invoking this command makes the matches
+for the next tag (or set of tags) be used. Repeatedly invoking this
+command makes the following tags be used. To be able to complete the
+matches selected by tt(_next_tags), the tt(completer) style should
+contain tt(_next_tags) as its first string. With that, the normal key
+binding (normally tt(TAB)) can be used to complete the matches shown
+after the call to tt(_next_tags).
+)
 findex(_read_comp (^X^R))
 item(tt(_read_comp (^X^R)))(
 Prompt the user for a string, and use that to perform completion on the
diff -ru ../z.old/Functions/Misc/.distfiles Functions/Misc/.distfiles
--- ../z.old/Functions/Misc/.distfiles	Mon Mar 13 11:02:45 2000
+++ Functions/Misc/.distfiles	Mon Mar 13 11:12:41 2000
@@ -2,5 +2,5 @@
     .distfiles
     acx allopt cat cdmatch cdmatch2 checkmail colors cx harden 
     is-at-least mere multicomp nslookup proto pushd randline
-    run-help yp yu zed zless zls zmv
+    run-help yp yu zed zless zls zmv zrecompile
 '

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

RE: Matching against file suffix

[Andrej Borsenkow]

>
> My first reaction was: yes. My second reaction: so what? ;-)
>
> Maybe I'm too slow in the brain today, but... what exactly do you want
> to say? You selected the order explicitly. If you want to see foo2,
> you have to give the tag in one string

...

>
> Or maybe you want to have a way to switch from one type of matches to
> the `next'.

Yes. Intent was to see "the most probable" matches first to keep list small, but still be
able to select more general ones.

Setting tag "in one string" completes both, but it also lists both.

-andrej

RE: Matching against file suffix

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > >
> > > That reminds me. Matcher-list is way too general - it applies to any completion in any
> > > context. And matcher is tried unconditionally, isn't it?
> >
> > I'm not sure what you mean by `unconditionally' -- I always consider
> > the context for which it is set to be a `condition'.
> >
> 
> I mean, that if matcher style is set for a tag, it is always used. I have no way to
> emulate matcher-list with semantic "try each in turn until you get matches".

Yep, see 10027 where I tried to explain why I haven't implemented
it. Btw, if someone sees a way around the problems mentioned there,
I'd be interested to hear about it.

> One more (well, somewhat different) question. I tried to play with tag-order.
> Unfortunately, it has one nasty effect - you cannot reject current tag.
> 
> With
> 
> zstyle ':completion:*:complete:cd:*' tag-order local-directories path-direcories
> 
> and
> 
> ./foo1
> foo2 somewhere in $cdpath
> 
> cd fTAB
> 
> will never complete foo2.
> 
> I think, it was discussed at least once, but may be in different context.
> 
> The same is true for example in docs (gunzip). If no *.gz exists but you have a
> subdirectory, you will never get a chance to complete other file.
> 
> Or did I miss something?

My first reaction was: yes. My second reaction: so what? ;-)

Maybe I'm too slow in the brain today, but... what exactly do you want 
to say? You selected the order explicitly. If you want to see foo2,
you have to give the tag in one string (I guess you are aware of that
-- just making sure):

  zstyle ':completion:*:complete:cd:*' tag-order 'local-directories path-direcories'

(note the quotes). With gunzip this is slightly different, because we
have a default for the order of globbed-files/directories/all-files.
Maybe you prefer:

  zstyle ... tag-order globbed-files all-files

Or maybe you want to have a way to switch from one type of matches to
the `next'. That would be nice, yes. It's just that nobody didn't find 
the time to write that yet -- maybe a bindable command, working a bit
like _complete_help, gathering possible tags and then selecting one of 
them... (I haven't missed that yet, that's why I haven't tried to
write it).


Bye
 Sven


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

RE: Matching against file suffix

[Andrej Borsenkow]

> >
> > That reminds me. Matcher-list is way too general - it applies to any completion in any
> > context. And matcher is tried unconditionally, isn't it?
>
> I'm not sure what you mean by `unconditionally' -- I always consider
> the context for which it is set to be a `condition'.
>

I mean, that if matcher style is set for a tag, it is always used. I have no way to
emulate matcher-list with semantic "try each in turn until you get matches".


One more (well, somewhat different) question. I tried to play with tag-order.
Unfortunately, it has one nasty effect - you cannot reject current tag.

With

zstyle ':completion:*:complete:cd:*' tag-order local-directories path-direcories

and

./foo1
foo2 somewhere in $cdpath

cd fTAB

will never complete foo2.

I think, it was discussed at least once, but may be in different context.

The same is true for example in docs (gunzip). If no *.gz exists but you have a
subdirectory, you will never get a chance to complete other file.

Or did I miss something?

-andrej

RE: Matching against file suffix

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > The simple 'r:|.=* r:|=*' works for me, i.e. `foo .../.texi<TAB>'
> > gives me the *.texi files.
> >
> 
> Well, I never could completely grok matchers :-)
> 
> Still, it seems, that with above matcher zsh considers only first dot. E.g.
> 
> zstyle ':completion:*:*:files' matcher 'r:|.=* r:|=*'
> bor@itsrm2% l
> WinNT/                    patches/                  zsh-3.1.6-dev-15.tar.gz
> zsh-3.1.6-dev-16.tar.gz   zsh-3.1.6-dev-17.tar.gz   zsh-3.1.6-dev-18.tar.gz
> zsh-3.1.6-dev-19.tar.gz   zsh-3.1.6.tar.gz
> bor@itsrm2% l .gz<TAB>
> 	beeps, but
> bor@itsrm2% l .1<TAB>
> bor@itsrm2% l zsh-3.1.6.tar.gz
> Completing file
> zsh-3.1.6-dev-15.tar.gz   zsh-3.1.6-dev-16.tar.gz   zsh-3.1.6-dev-17.tar.gz
> zsh-3.1.6-dev-18.tar.gz   zsh-3.1.6-dev-19.tar.gz   zsh-3.1.6.tar.gz
> 
> I vaguelly remember, that it was once done on purpose. While I agree, that it may be
> useful at times - is it possible to have alternate way that matches separators as well? Or
> some other way to get the above?

Urgh. We had so many problems with that, that I would prefer to not
change (or enhance) it again. Hm, a pure suffix test match spec would
be `l:|=*' (read: there may be any characters before the word typed).

[ Btw. tcsh with complete=enhance does the same -- by which I don't
  want to say that it is the correct behaviour. ;-]

And...

> In the above case I'd like being able to say
> 
> gzcat -19TAB (or even -6-19)
> and get it expanded to zsh-3.1.6-dev-19.tar.gz

this (the `-19<TAB>', not the `-6-19<TAB>') is exactly what I use the
substring-matcher for: `l:|=* r:|=*' means that there may be any
characetrs before or after the word from the line.

> > Btw, I have the _match completer in my completer style, but only after
> > all the matcher-list specs have been tried (which include the one
> > above and the substring-matcher `l:|=* r:|=*').
> 
> That reminds me. Matcher-list is way too general - it applies to any completion in any
> context. And matcher is tried unconditionally, isn't it?

I'm not sure what you mean by `unconditionally' -- I always consider
the context for which it is set to be a `condition'.

> Is there any feasible way to add
> per-tag matcher-list? So, that one could say
> 
> *files matcher-list ...

I've been dreaming about this, too. But -- as you can see -- I didn't
find a solution. There are actually two problems:

- Testing multiple patterns would require a loop somewhere. Since
  nobody will suggest that every completion function should implement
  such a loop, we could put it in compadd (i.e. in C-code). We would
  then need another option to give it a bunch of match specs to try
  one after another. That's not too hard. But:
- The second problem is to decide when to try the next pattern.
  Consider a context where we can add more than one type of
  matches. Here we almost certainly first want to try all types with
  the first match spec, then try all types with the next pattern and
  so on. In other words: we can write the loop only in the completion
  functions. Even worse: only in the top-level functions. And now
  think about functions like _users which are sometimes called as
  top-level functions and sometimes as utility functions. And we can't 
  put the loop(s) in a function further up (like _normal), because we
  don't know about the tags there.

Sigh.

Bye
 Sven


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

RE: Matching against file suffix

[Andrej Borsenkow]

>
> The simple 'r:|.=* r:|=*' works for me, i.e. `foo .../.texi<TAB>'
> gives me the *.texi files.
>

Well, I never could completely grok matchers :-)

Still, it seems, that with above matcher zsh considers only first dot. E.g.

zstyle ':completion:*:*:files' matcher 'r:|.=* r:|=*'
bor@itsrm2% l
WinNT/                    patches/                  zsh-3.1.6-dev-15.tar.gz
zsh-3.1.6-dev-16.tar.gz   zsh-3.1.6-dev-17.tar.gz   zsh-3.1.6-dev-18.tar.gz
zsh-3.1.6-dev-19.tar.gz   zsh-3.1.6.tar.gz
bor@itsrm2% l .gz<TAB>
	beeps, but
bor@itsrm2% l .1<TAB>
bor@itsrm2% l zsh-3.1.6.tar.gz
Completing file
zsh-3.1.6-dev-15.tar.gz   zsh-3.1.6-dev-16.tar.gz   zsh-3.1.6-dev-17.tar.gz
zsh-3.1.6-dev-18.tar.gz   zsh-3.1.6-dev-19.tar.gz   zsh-3.1.6.tar.gz

I vaguelly remember, that it was once done on purpose. While I agree, that it may be
useful at times - is it possible to have alternate way that matches separators as well? Or
some other way to get the above?

In the above case I'd like being able to say

gzcat -19TAB (or even -6-19)
and get it expanded to zsh-3.1.6-dev-19.tar.gz


> Btw, I have the _match completer in my completer style, but only after
> all the matcher-list specs have been tried (which include the one
> above and the substring-matcher `l:|=* r:|=*').
>


That reminds me. Matcher-list is way too general - it applies to any completion in any
context. And matcher is tried unconditionally, isn't it? Is there any feasible way to add
per-tag matcher-list? So, that one could say

*files matcher-list ...

-andrej

Re: Matching against file suffix

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> So far, the two major uses I had for globbing were:
> 
> 1. patch < /.../zsh/patches/<1234->TAB
> 
> This is nice for manually applying patches; I save them with article number and simply get
> the next by incrementing number and hitting TAB
> 
> 2. foo .../zsh/Doc/*.texi
> 
> That is the case, when I do know file suffix and want to get just this one file.
> Unfortunately, as was oft seen, this has problems with _path_files - and, Sven, you once
> wrote, that you do not use globbing at all but use spiffy match controls instead.
> 
> Is it possible to match by file suffix with matching control? It is 'course possible by
> moving cursor before suffix - but that I'd like to avoid. The idea is to hit TAB at the
> end of input word and still get completion.

The simple 'r:|.=* r:|=*' works for me, i.e. `foo .../.texi<TAB>'
gives me the *.texi files.

Btw, I have the _match completer in my completer style, but only after
all the matcher-list specs have been tried (which include the one
above and the substring-matcher `l:|=* r:|=*').

Bye
 Sven


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