Re: Completion issues

Re: Completion issues

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> Tail-ender:  this is a real bug:
>   % zsh -f
>   % autoload -U compinit; compinit -D
>   % zstyle ':completion:*' completer _expand _complete
>   % zstyle ':<TAB>
>            ^this gets replaced by an character from the upper end of
>             ISO-8859-1 which I didn't particularly want to see.

We need to copy the quoted prefix/suffix when putting them into the
cline.


I've update the ChangeLog for the stuff from yesterday... but rcs2log
is completely unusable for me because it takes ages (so long that I
haven't let it run until the end). Is there a tool to get a ChangeLog
entry template from a diff? Or do I have to write that myself?

Bye
 Sven

Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.2
diff -u -r1.2 compcore.c
--- Src/Zle/compcore.c	2000/04/01 20:49:48	1.2
+++ Src/Zle/compcore.c	2000/04/04 09:42:00
@@ -1982,7 +1982,7 @@
 	    sl = tsl;
 	}
 	if (qisl) {
-	    Cline qsl = bld_parts(qisuf, qisl, qisl, NULL);
+	    Cline qsl = bld_parts(dupstring(qisuf), qisl, qisl, NULL);
 
 	    qsl->flags |= CLF_SUF;
 	    qsl->suffix = qsl->prefix;
@@ -2065,7 +2065,7 @@
 	    line = p;
 	}
 	if (qipl) {
-	    Cline lp, p = bld_parts(qipre, qipl, qipl, &lp);
+	    Cline lp, p = bld_parts(dupstring(qipre), qipl, qipl, &lp);
 
 	    lp->next = line;
 	    line = p;

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

More SourceForge issues (Was: Completion issues)

[Geoff Wing]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> typed:
:I've update the ChangeLog for the stuff from yesterday... but rcs2log
:is completely unusable for me because it takes ages (so long that I
:haven't let it run until the end).

rcs2log is really only useful for generating your own ChangeLog entry.
Previous commits by someone else which aren't in the ChangeLog would
need manual adjustment of names & email addresses.  Even if run on
sourceforge (to speed it up) it would still need email addresses updated.
However, I might have missed the decision on how ChangeLog is to be
updated but I would have presumed that people would use useful commit
messages and then the ChangeLog could be generated just before a release
from those messages (and name/email addresses can be replaced then) - the
only real difference to our current ChangeLog format being that files
affected are also listed (and it might not be quite as pretty)

:Is there a tool to get a ChangeLog
:entry template from a diff? Or do I have to write that myself?

One other option is to overload the (currently) theoretical aggregating
commit message tool to also dump info out to some other area (although this
is more complicated since it's hosted on another machine to that we can
run tools on).  Of course, if each developer is responsible for updating
ChangeLog hirself then just save the commit message file to something else
when you're committing and then you've got it handy.
(Or the longer way would be do rcs2log on just those files you updated and
use the appropriate part of ChangeLog generated).

Do people on zsh-workers want to see all these SourceForge messages (to
keep abreast with what's happening or whatever) or is it more suitable
off this list to amongst those developing on SourceForge?

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: Completion issues

[Sven Wischnowsky]

Peter Stephenson wrote:

> > > Another thing:  I couldn't get matcher-list to work for a labelled
> > > completer, e.g. _complete:-extended.
> 
> This seems to work this time.  Don't what I did wrong.  So what's the
> difference between matcher and matcher-list now?  The latter is looked up
> once for a completer (but again if we have a labelled completer), but the
> latter is looked up every single time we add a match?

Two main differences:

1) matcher is tested for the most specific contexts possible,
   including the tags, matcher-list, as you said, only for the
   completer

2) matcher-list uses its values on after another (there is a loop),
   matcher uses all its values in one go

But, yes, with completer-labelling one could replace matcher-list with 
a couple of matcher styles settings. Exactly because of that `couple of'
I kept matcher-list -- it's so much more convenient.

Bye
 Sven


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

Re: Completion issues

[Peter Stephenson]

Sven Wischnowsky wrote:
> Hm. Should we add a tag-labels style again (tested for every tag in
> tag-order, gives labels to use for this tag in its value)? My main
> reason for not liking this that much is the fact that it's in C now -- 
> I wanted to avoid having style-lookups hidden in some C-function.

As long as it works, which it does now, I'm not worried.

> > I would expect the following to work:
> >   zstyle ':completion:*:sequences' tag-order sequences:-name sequences:-num
> >   zstlye ':completion:*:sequences-name' ignored-patterns '<->'
> >   zstyle ':completion:*:sequences-num' ignored-patterns '^<->'

This now works, too

> > Another thing:  I couldn't get matcher-list to work for a labelled
> > completer, e.g. _complete:-extended.

This seems to work this time.  Don't what I did wrong.  So what's the
difference between matcher and matcher-list now?  The latter is looked up
once for a completer (but again if we have a labelled completer), but the
latter is looked up every single time we add a match?

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Completion issues

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
>
> I tried this:
>  zstyle ':completion:*:*:-command-:*' tag-order \
>    'functions:-non-comp:non-completion\ functions *' functions
>  zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
> pretty much what's in the manual, except with a name.  Now listing
> completions for zfl gives me
>   Completing non-completion functions
>   zfls 
>   Completing shell function
>   zfls 
>   Completing alias
>   zfls 
> Forget the last one; arguably you should only get the alias in this case,
> since that's what will actually run, but I can see that's a
> sophistication.  It's a bit annoying that I get the same function, for the
> same tag, both with filtering and without.  With a long list it's going to
> be worse.  Have I missed something?

No, my fault. The patterns should be replaced only with the tags
offered which are not yet given directly in the same string (with or
without a label). I forgot to re-implement that when moving the stuff
from shell code to C.

> ...
> 
> The only problem there is I don't really want to upset the
> global tag-order for what is really a local problem for one tag.  So I
> replaced the first line with:
>   zstyle ':completion:*:functions' tag-order functions:-non-comp
> This doesn't work, and I can understand why it wouldn't --- looking up a
> tag using a tag is distinctly odd.  But the manual implies this works with
> options:
>   zstyle ':completion:*:options' tag-order 'options:-long:long options
>         options:-short:short options
>         options:-single-letter:single letter options'
> (formatted here with a ghastly offset of some thirty characters but I
> suppose that's my problem). 

Urgh. Of course that should have been only `:completion:*', without
the `options'.

> As a subsidiary question, what happened to the
> backslashes the manual claims are needed for the spaces in the names? More
> importantly, what the heck's going on? Apparently looking up the tag
> `options' will, after all, force a re-lookup with options split into three.
> As far as I can see, this example is the only thing in the manual which
> tells you one way or the other whether you can explicitly split up tags
> into sub-tags like this. I'm now distinctly confused.  Explanation?

I copied that from the late tag-aliases style, which could be set for
single tags and got the aliases/labels in separate words -- then I
forgot to remove the `:options' and insert the backslashes.

Hm. Your `don't really want to upset the global tag-order for what is
really a local problem'... that's what I intended the tag-aliases
styles for. But then I thought tag-order is enough -- as in the
example from the manual (once it is corrected by the patch
below). This may look a bit ugly, but if your main concern is speed:
this is done in C now, so it really isn't that expensive.

Hm. Should we add a tag-labels style again (tested for every tag in
tag-order, gives labels to use for this tag in its value)? My main
reason for not liking this that much is the fact that it's in C now -- 
I wanted to avoid having style-lookups hidden in some C-function.

So the question is: move things in shell code again, and add
tag-labels or leave it as it is. Unless someone sees a way to combine
them, of course.

> I came across the same problem when trying to explain _next_label using the
> code in _mh.  Looking at the code, which is this:
>   if _wanted sequences; then
>     while _next_label sequences expl sequence; do
>       compadd "$expl[@]" $(mark $foldnam 2>/dev/null | 
> 			   awk -F: '{ print $1 }') &&
>         ret=0
>       compadd "$expl[@]" reply next cur prev first last all unseen && ret=0
>       _files "$expl[@]" -W folddir -g '<->' && ret=0
>       (( ret )) || return 0
>     done
> I would expect the following to work:
>   zstyle ':completion:*:sequences' tag-order sequences:-name sequences:-num
>   zstlye ':completion:*:sequences-name' ignored-patterns '<->'
>   zstyle ':completion:*:sequences-num' ignored-patterns '^<->'
> prefering named sequences to messages which are just numbers.  But it
> doesn't.  I noted that despite being inside the _wanted, _files is used
> instead of _path_files, so I thought maybe it was using the files tag, but
> assuming a split into `sequences' and `files' doesn't seem to work either.
> What's the right way of doing this?

The way you did, with the patch below. The problem was that _files
didn't make sure that the ignored patterns also used the ones given to 
_files. Another problem was the `(( ret ) || ...'. That shouldn't be
inside the label-loop (after all, we are looping over the labels that
have to be tried at the same time). This was wrong in several
completion functions.

Note, however, that _next_tags currently isn't smart enough to get
switching from one label to the next right. Hm, I've got to think some 
more about this...

> By the way, the example given in the manual of ignored-patterns and tag
> labels,
>   zstyle ':completion:*:*:-command-:*' tag-order 'functions:-non-comp'
>   zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
> (= in command position, prefer the `functions' tag but use it with the name
> functions-non-comp; anywhere you see that tag, exclude patterns matching
> `_*) isn't particularly good, since the issue only really arises in command
> position after you've typed a character, hence you really need
> correction/approximation to test this, and it's hard to think of an
> example.  I've borrowed this from the manual until I or someone else can
> think of another clean, simple example.

`nohup <TAB>'. But I agree, that it's a bad example. In fact, I tried
to think of a better one when I wrote that.

> Another thing:  I couldn't get matcher-list to work for a labelled
> completer, e.g. _complete:-extended.  When I switched to matcher instead,
> it worked fine.  This fit my preconception, when I eventually decided what
> that would have been, because I though matcher-list was decided once right
> at the start.  However, the manual explicitly says that you can use
> matcher-list with labelled completers.

And it works for me:

  zstyle ':completion:*' completer _complete:-foo
  zstyle ':completion:*:complete-foo:*' matcher-list '' 'm:{a-z}={A-Z}'

Note how the name of the completer is changed for lookup.

> Tail-ender:  this is a real bug:
>   % zsh -f
>   % autoload -U compinit; compinit -D
>   % zstyle ':completion:*' completer _expand _complete
>   % zstyle ':<TAB>
>            ^this gets replaced by an character from the upper end of
>             ISO-8859-1 which I didn't particularly want to see.
> 
> The style subst-globs-only is several times referred to without the
> plural, which is particularly annoying in _zstyle, but also occurs in the
> doc.  (No patch, since it's almost half past midnight and I like to eat
> this evening.)

No patch for this yet...

> This is probably known, but _next_tags doesn't work well with menu
> completion.  Ideally, it should probably remove the current choice if the
> last command was a menu completion and replace it with the first choice
> from the list generated with the next tag.


> Also, the message at the top
> doesn't change; you still see `Completing TeX or LaTeX file' if you cycle
> through to completing directories.  Maybe this is a feature.

That's because the default for the file-patterns style doesn't add
descriptions, so the one given by the calling function is used. I has
always been like that. But I agree that it's particularly irritating
wiht _next_tags.

Bye
 Sven

Index: Completion/Core/_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_files,v
retrieving revision 1.2
diff -u -r1.2 _files
--- Completion/Core/_files	2000/04/01 20:43:43	1.2
+++ Completion/Core/_files	2000/04/03 15:25:30
@@ -1,12 +1,23 @@
 #autoload
 
-local opts tmp glob pats expl tag i pat descr minus
+local opts tmp glob pats expl tag i pat descr end ign ret=1
 
 zparseopts -a opts \
     '/=tmp' 'f=tmp' 'g+:-=tmp' q n 1 2 P: S: r: R: W: X+: M+: F: J+: V+:
 
 type="${(@j::M)${(@)tmp#-}#?}"
 (( $tmp[(I)-g*] )) && glob="${(j: :)${(M)tmp:#-g*}#-g}"
+ign=$opts[(I)-F]
+if (( ign )); then
+  ign=( $=opts[ign+1] )
+  if [[ $ign = _comp_ignore ]]; then
+    ign=( $_comp_ignore )
+  else
+    opts[tmp+1]=_comp_ignore
+  fi
+else
+  ign=
+fi
 
 if zstyle -a ":completion:${curcontext}:" file-patterns pats; then
   [[ "$type" = */* ]] && glob="$glob *(-/)"
@@ -34,16 +45,24 @@
   if [[ i -gt 0 && "$pat" != \ # ]]; then
     if [[ "$pats[i]" = *:${tag}:* ]]; then
       descr="${pats[i]#*:${tag}:}"
-      minus=()
     else
       descr=file
-      minus=(-)
+      end=yes
     fi
   fi
-
-  _wanted "$tag" expl "$descr" \
-      _path_files -g "$pat" "$opts[@]" "$minus[@]" && return 0
 
+  if _wanted "$tag"; then
+    _comp_ignore=()
+    while _next_label "$tag" expl "$descr"; do
+      _comp_ignore=( $_comp_ignored $ign )
+      if [[ -n "$end" ]]; then
+        _path_files -g "$pat" "$opts[@]" "$expl[@]" && ret=0
+      else
+        _path_files "$expl[@]" -g "$pat" "$opts[@]" && ret=0
+      fi
+    done
+    (( ret )) || return 0
+  fi
 done
 
 return 1
Index: Completion/User/_gdb
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_gdb,v
retrieving revision 1.2
diff -u -r1.2 _gdb
--- Completion/User/_gdb	2000/04/01 20:43:43	1.2
+++ Completion/User/_gdb	2000/04/03 15:25:30
@@ -23,8 +23,8 @@
                                   -directory\= -cd\= -tty\= && ret=0
       compadd "$expl[@]"        - -help -h -s -e -c -x -d -nx -n -quiet -q \
 	    		          -batch -fullname -f -b && ret=0
-      (( ret )) || return 0
     done
+    (( ret )) || return 0
   fi
 else
   prev="$words[CURRENT-1]"
Index: Completion/User/_getconf
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_getconf,v
retrieving revision 1.2
diff -u -r1.2 _getconf
--- Completion/User/_getconf	2000/04/01 20:43:43	1.2
+++ Completion/User/_getconf	2000/04/03 15:25:30
@@ -29,7 +29,6 @@
                                    _POSIX_NO_TRUNC _POSIX_VDISABLE && ret=0
           compadd "$expl[@]" -S ' ' LINK_MAX MAX_CANON MAX_INPUT NAME_MAX \
                                     PATH_MAX PIPE_BUF && ret=0
-          (( ret )) || break
         done
     (( ret )) || return 0
   done
Index: Completion/User/_mh
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_mh,v
retrieving revision 1.2
diff -u -r1.2 _mh
--- Completion/User/_mh	2000/04/01 20:43:43	1.2
+++ Completion/User/_mh	2000/04/03 15:25:30
@@ -78,7 +78,6 @@
         ret=0
       compadd "$expl[@]" reply next cur prev first last all unseen && ret=0
       _files "$expl[@]" -W folddir -g '<->' && ret=0
-      (( ret )) || return 0
     done
   fi
   return ret
Index: Completion/User/_netscape
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_netscape,v
retrieving revision 1.2
diff -u -r1.2 _netscape
--- Completion/User/_netscape	2000/04/01 20:43:43	1.2
+++ Completion/User/_netscape	2000/04/03 15:25:30
@@ -82,7 +82,6 @@
       while _next_label prefixes expl 'URL prefix'; do
         compadd "$expl[@]" -S '' about: mocha: javascript: && ret=0
         _urls "$@" && ret=0
-	(( ret )) || return 0
       done
     fi
   fi
Index: Completion/User/_tiff
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_tiff,v
retrieving revision 1.2
diff -u -r1.2 _tiff
--- Completion/User/_tiff	2000/04/01 20:43:43	1.2
+++ Completion/User/_tiff	2000/04/03 15:25:30
@@ -199,7 +199,6 @@
       while _next_label values expl 'compression scheme'; do
         compadd "$expl[@]" - none g4 packbits && ret=0
         compadd "$expl[@]" -qS: - lzw zip jpeg g3 && ret=0
-	(( ret )) || return 0
       done
     fi
   fi
Index: Completion/User/_urls
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_urls,v
retrieving revision 1.2
diff -u -r1.2 _urls
--- Completion/User/_urls	2000/04/01 20:43:43	1.2
+++ Completion/User/_urls	2000/04/03 15:25:30
@@ -59,7 +59,6 @@
     [[ -d $urls_path/bookmark ]] &&
       compadd "$expl[@]" -S '' bookmark: && ret=0
     compadd "$expl[@]" -S '' file: ftp:// gopher:// http:// && ret=0
-    (( ret )) || return 0
   done
   return ret
 fi
@@ -83,7 +82,6 @@
         elif [[ -z "$PREFIX" ]]; then
 	  compadd "$expl[@]" -S '/' -r '/' - "${PWD%/}" && ret=0
         fi
-	(( ret )) || return 0
       done
       return ret
     fi
@@ -100,7 +98,6 @@
           _path_files -W "$urls_path/$scheme" "$expl[@]" -S '' -g '*(^/)' && 
               ret=0
           _path_files -W "$urls_path/$scheme" -S/ -r '/' -/ && ret=0
-          (( ret )) || return 0
         done
       fi
     fi
@@ -116,7 +113,6 @@
     (( $#uhosts )) || _hosts -S/ && ret=0
     [[ "$scheme" = http ]] && uhosts=($uhosts $localhttp_servername)
     compadd "$expl[@]" -S/ - $uhosts && ret=0
-    (( ret )) || return 0
   done
   return ret
 fi
@@ -136,20 +132,17 @@
     while _next_label files expl 'local file'; do
       _path_files "$expl[@]" -W ~$user/$localhttp_userdir -g '*(^/)' && ret=0
       _path_files "$expl[@]" -W ~$user/$localhttp_userdir -S/ -r '/' -/ && ret=0
-      (( ret )) || return 0
     done
   else
     while _next_label files expl 'local file'; do
       _path_files "$expl[@]" -W $localhttp_documentroot -g '*(^/)' && ret=0
       _path_files "$expl[@]" -W $localhttp_documentroot -S/ -r '/' -/ && ret=0
-      (( ret )) || return 0
     done
   fi
 else
   while _next_label files expl 'local file'; do
     _path_files "$expl[@]" -W $urls_path/$scheme/$host -g '*(^/)' && ret=0
     _path_files "$expl[@]" -W $urls_path/$scheme/$host -S/ -r '/' -/ && ret=0
-    (( ret )) || return 0
   done
 fi
 return $ret
Index: Completion/X/_xmodmap
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/_xmodmap,v
retrieving revision 1.2
diff -u -r1.2 _xmodmap
--- Completion/X/_xmodmap	2000/04/01 20:43:43	1.2
+++ Completion/X/_xmodmap	2000/04/03 15:25:30
@@ -86,7 +86,6 @@
       while _next_label commands expl command; do
         compadd "$expl[@]" -S ' ' keycode keysym clear add remove && ret=0
         compadd "$expl[@]" -S ' = ' pointer && ret=0
-        (( ret )) || return 0
       done
     fi
   fi
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.4
diff -u -r1.4 compsys.yo
--- Doc/Zsh/compsys.yo	2000/04/03 13:13:02	1.4
+++ Doc/Zsh/compsys.yo	2000/04/03 15:25:31
@@ -1651,10 +1651,10 @@
 Of course, this can also be used to split the matches for one tag into 
 different groups. For example:
 
-example(zstyle ':completion:*:options' tag-order \
-    'options:-long:long options
-     options:-short:short options
-     options:-single-letter:single letter options'
+example(zstyle ':completion:*' tag-order \
+    'options:-long:long\ options
+     options:-short:short\ options
+     options:-single-letter:single\ letter\ options'
 
 zstyle ':completion:*:options-long' ignored-patterns '[-+](|-|[^-]*)'
 zstyle ':completion:*:options-short' ignored-patterns '--*' '[-+]?'
Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.2
diff -u -r1.2 computil.c
--- Src/Zle/computil.c	2000/04/01 20:49:48	1.2
+++ Src/Zle/computil.c	2000/04/03 15:25:32
@@ -2405,7 +2405,7 @@
 		while (*s) {
 		    while (*s && iblank(*s))
 			s++;
-		    for (p = q = s, c = NULL; *s && !iblank(*s); s++) {
+		    for (p = q = s, c = NULL; *s && !inblank(*s); s++) {
 			if (!c && *s == ':')
 			    c = p;
 			if (*s == '\\' && s[1])
@@ -2423,12 +2423,26 @@
 			tokenize(qq);
 			if (haswilds(qq)) {
 			    Patprog prog;
+			    LinkNode node;
 
 			    if ((prog = patcompile(qq, PAT_STATIC, NULL))) {
 				char **a, *n;
 				int l = (c ? strlen(c + 1) + 2 : 1), al;
 
 				for (a = all; *a; a++) {
+				    for (node = firstnode(list); node;
+					 incnode(node)) {
+					char *as, *ls;
+
+					for (as = *a, ls = (char *) getdata(node);
+					     *as && *ls && *ls != ':'; as++, ls++)
+					    if (*as != *ls)
+						break;
+					if (!*as && (!*ls || *ls == ':'))
+					    break;
+				    }
+				    if (node)
+					continue;
 				    if (pattry(prog, *a)) {
 					n = (char *) zhalloc((al = strlen(*a)) + l);
 					strcpy(n, *a);

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

Re: Completion issues

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 1,  9:26pm, Peter Stephenson wrote:
> ...
> 
> } Second, if I understood correctly, the default behaviour for completion is
> } to ignore ignored completions completely.  Thus the behaviour of $fignore
> } has changed.
> 
> Unless I'm getting the wrong version of a function, it appears that this
> is special-cased by _path_files so that $fignore has not changed -- but
> if you use the ignored-patterns style instead, then ignored completions
> really are ignored, and you need to add the _ignored completer to get
> the old behavior back.

No, $fignore is used in the same way as ignored-patterns (and ignored
only by _ignored).

So, this changes the default for the completer style.

Bye
 Sven

Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.2
diff -u -r1.2 _main_complete
--- Completion/Core/_main_complete	2000/04/01 20:43:43	1.2
+++ Completion/Core/_main_complete	2000/04/03 13:07:22
@@ -62,7 +62,7 @@
   _completers=( "$@" )
 else
   zstyle -a ":completion:${curcontext}:" completer _completers ||
-      _completers=( _complete )
+      _completers=( _complete _ignored )
 fi
 
 # And now just call the completer functions defined.
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.3
diff -u -r1.3 compsys.yo
--- Doc/Zsh/compsys.yo	2000/04/03 12:56:31	1.3
+++ Doc/Zsh/compsys.yo	2000/04/03 13:07:25
@@ -841,8 +841,10 @@
 zstyle ':completion:incremental:*' completer _complete _correct
 zstyle ':completion:predict:*' completer _complete)
 
-The default value for this style is tt(_complete), i.e. normally only
-completion will be done.
+The default value for this style is tt(_complete _ignored),
+i.e. normally only completion will be done, first using the
+tt(ignored-patterns) style and the tt($fignore) array and then without 
+ignoring matches because of these.
 )
 kindex(completions, completion style)
 item(tt(completions))(

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

Re: Completion issues

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 1,  9:26pm, Peter Stephenson wrote:
> } Subject: Completion issues
> }
> } First, I hate the new behaviour of _complete_help.  I use it to find out
> } what context I'm in.  Unfortunately I don't get to see that, because a huge
> } list of style has scrolled by.
> 
> I won't say I *hate* the new behavior, but I was certainly alarmed by the
> amount of style output that was generated even for something like "ls" or
> "echo" that doesn't have any special handling.  "cvs <^Xh>" is horrifying.
> That list-colors, list-packed, list-rows-first, last-prompt, accept-exact,
> and menu appear no less than 8 times each seems a tad excessive.

I get them only three times -- it all depends on ones setup...

> } I don't think a style to turn off styles in ^Xh is good enough,
> } there's too much mucking around, and you may want the style information
> } anyway.  A workable alternative is that a numeric argument activates the
> } style list --- this feature could be configurable by a style.
> 
> I like the numeric-argument idea.  If we wanted to get really fancy, a
> number from 1-4 could denote increasingly verbose output, so that using
> universal-argument would produce the full-blown listing.
> 
> I'm not convinced we'd need a style to make that configurable, though.
> It's pretty straightforward to create a zle widget that sets NUMERIC and
> then calls another widget.

Ok. The patch makes the style list be shown only if _complete_help is
given a numeric argument.

I haven't tried to make this support multiple levels of verboseness
yet. The only probelm I have with that is to decide what to show on
the intermediate levels, though. I mean, for example, showing the
styles used without the contexts in which they are used can be both
misleading and useless. In some cases. I think. Hm.

Bye
 Sven

Index: Completion/Commands/_complete_help
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_complete_help,v
retrieving revision 1.2
diff -u -r1.2 _complete_help
--- Completion/Commands/_complete_help	2000/04/01 20:43:43	1.2
+++ Completion/Commands/_complete_help	2000/04/03 12:50:02
@@ -44,21 +44,22 @@
     text="${text}${tmp}"
   done
 
-  text="$text
+  if [[ ${NUMERIC:-1} -ne 1 ]]; then
+    text="$text
 "
-  for i in "${(@ok)help_sfuncs}"; do
-    text="${text}
+    for i in "${(@ok)help_sfuncs}"; do
+      text="${text}
 styles in context ${i}"
-    tmp=()
-    for j in "${(@s.:.)help_sfuncs[$i][2,-1]}"; do
-      tmp=( "$tmp[@]" "${(@s.,.)help_styles[${i}${j}][2,-1]}" )
-    done
-    zformat -a tmp '  (' "$tmp[@]"
-    tmp=( '
+      tmp=()
+      for j in "${(@s.:.)help_sfuncs[$i][2,-1]}"; do
+        tmp=( "$tmp[@]" "${(@s.,.)help_styles[${i}${j}][2,-1]}" )
+      done
+      zformat -a tmp '  (' "$tmp[@]"
+      tmp=( '
     '${^tmp}')' )
-    text="${text}${tmp}"
-  done
-
+      text="${text}${tmp}"
+    done
+  fi
   compstate[list]='list force'
   compstate[insert]=''
 
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.2
diff -u -r1.2 compsys.yo
--- Doc/Zsh/compsys.yo	2000/04/01 20:43:44	1.2
+++ Doc/Zsh/compsys.yo	2000/04/03 12:50:05
@@ -355,8 +355,7 @@
 ifnzman(noderef(Bindable Commands))
 can be invoked to find out the context and tag names and styles used at a particular
 point in completion.  It shows a list of context names and the 
-tag names used in those contexts and then a list of context names and
-the styles used in those contexts if completion were tried at the
+tag names used in those contexts if completion were tried at the
 current cursor position.  Hence one can easily find out all the
 information needed to change the behaviour of the tt(tag-order) style
 for a particular context.
@@ -2200,8 +2199,10 @@
 findex(_complete_help (^Xh))
 item(tt(_complete_help (^Xh)))(
 This widget displays information about the context names, 
-the tags, the styles, and the completion functions used 
-when completing at the current cursor position.
+the tags, and the completion functions used 
+when completing at the current cursor position. If given a numeric
+argument other than tt(1) (as in `tt(ESC-2 ^Xh)'), then the styles
+used and the contexts for which they are used will be shown, too.
 
 Note that, depending on the control flow in the completion functions
 called, the information about the styles may be

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

Re: Completion issues

[Bart Schaefer]

On Apr 1,  9:26pm, Peter Stephenson wrote:
} Subject: Completion issues
}
} First, I hate the new behaviour of _complete_help.  I use it to find out
} what context I'm in.  Unfortunately I don't get to see that, because a huge
} list of style has scrolled by.

I won't say I *hate* the new behavior, but I was certainly alarmed by the
amount of style output that was generated even for something like "ls" or
"echo" that doesn't have any special handling.  "cvs <^Xh>" is horrifying.
That list-colors, list-packed, list-rows-first, last-prompt, accept-exact,
and menu appear no less than 8 times each seems a tad excessive.


} I don't think a style to turn off styles in ^Xh is good enough,
} there's too much mucking around, and you may want the style information
} anyway.  A workable alternative is that a numeric argument activates the
} style list --- this feature could be configurable by a style.

I like the numeric-argument idea.  If we wanted to get really fancy, a
number from 1-4 could denote increasingly verbose output, so that using
universal-argument would produce the full-blown listing.

I'm not convinced we'd need a style to make that configurable, though.
It's pretty straightforward to create a zle widget that sets NUMERIC and
then calls another widget.

} Second, if I understood correctly, the default behaviour for completion is
} to ignore ignored completions completely.  Thus the behaviour of $fignore
} has changed.

Unless I'm getting the wrong version of a function, it appears that this
is special-cased by _path_files so that $fignore has not changed -- but
if you use the ignored-patterns style instead, then ignored completions
really are ignored, and you need to add the _ignored completer to get
the old behavior back.

For the rest of the stuff you mentioned, I'm even more lost than you.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Completion issues

[Peter Stephenson]

Thanks to some notes from Sven, I was able to update chapter six of the
user guide, during which these matters arose.  When I understand them, I'll
upload the new version.  If that passes muster, I'll transfer it to the
main zsh web site.  I know Sven has actually asked about some of these,
including the first one.

First, I hate the new behaviour of _complete_help.  I use it to find out
what context I'm in.  Unfortunately I don't get to see that, because a huge
list of style has scrolled by.  This is useful information, but should be
decanted to another function --- perhaps _complete_long_help, with the
default binding ^X^H (? ^H has other uses, so maybe there's something
better).  I don't think a style to turn off styles in ^Xh is good enough,
there's too much mucking around, and you may want the style information
anyway.  A workable alternative is that a numeric argument activates the
style list --- this feature could be configurable by a style.

Second, if I understood correctly, the default behaviour for completion is
to ignore ignored completions completely.  Thus the behaviour of $fignore
has changed.  If this is right, _ignored should definitely be added to the
default completers.  Certainly people may prefer it without, but it should
be up to them to change the old behaviour.

Next, I'm in a mess with the tag label stuff.  First of all,
I tried this:
 zstyle ':completion:*:*:-command-:*' tag-order \
   'functions:-non-comp:non-completion\ functions *' functions
 zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
pretty much what's in the manual, except with a name.  Now listing
completions for zfl gives me
  Completing non-completion functions
  zfls 
  Completing shell function
  zfls 
  Completing alias
  zfls 
Forget the last one; arguably you should only get the alias in this case,
since that's what will actually run, but I can see that's a
sophistication.  It's a bit annoying that I get the same function, for the
same tag, both with filtering and without.  With a long list it's going to
be worse.  Have I missed something?

Also, if I remember right the tag label stuff was partly inspired by the
example in the guide about ignoring functions matching `_*'.  That can
still be done using _ignored; Sven's sent me how to do that for the guide.
It can also be done by:
  zstyle ':completion:*' tag-order functions:-non-comp
  zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
(for some reason didn't seem to work before, but does now, so I presume I
fouled up).  The only problem there is I don't really want to upset the
global tag-order for what is really a local problem for one tag.  So I
replaced the first line with:
  zstyle ':completion:*:functions' tag-order functions:-non-comp
This doesn't work, and I can understand why it wouldn't --- looking up a
tag using a tag is distinctly odd.  But the manual implies this works with
options:
  zstyle ':completion:*:options' tag-order 'options:-long:long options
        options:-short:short options
        options:-single-letter:single letter options'
(formatted here with a ghastly offset of some thirty characters but I
suppose that's my problem).  As a subsidiary question, what happened to the
backslashes the manual claims are needed for the spaces in the names? More
importantly, what the heck's going on? Apparently looking up the tag
`options' will, after all, force a re-lookup with options split into three.
As far as I can see, this example is the only thing in the manual which
tells you one way or the other whether you can explicitly split up tags
into sub-tags like this. I'm now distinctly confused.  Explanation?

I came across the same problem when trying to explain _next_label using the
code in _mh.  Looking at the code, which is this:
  if _wanted sequences; then
    while _next_label sequences expl sequence; do
      compadd "$expl[@]" $(mark $foldnam 2>/dev/null | 
			   awk -F: '{ print $1 }') &&
        ret=0
      compadd "$expl[@]" reply next cur prev first last all unseen && ret=0
      _files "$expl[@]" -W folddir -g '<->' && ret=0
      (( ret )) || return 0
    done
I would expect the following to work:
  zstyle ':completion:*:sequences' tag-order sequences:-name sequences:-num
  zstlye ':completion:*:sequences-name' ignored-patterns '<->'
  zstyle ':completion:*:sequences-num' ignored-patterns '^<->'
prefering named sequences to messages which are just numbers.  But it
doesn't.  I noted that despite being inside the _wanted, _files is used
instead of _path_files, so I thought maybe it was using the files tag, but
assuming a split into `sequences' and `files' doesn't seem to work either.
What's the right way of doing this?

By the way, the example given in the manual of ignored-patterns and tag
labels,
  zstyle ':completion:*:*:-command-:*' tag-order 'functions:-non-comp'
  zstyle ':completion:*:functions-non-comp' ignored-patterns '_*'
(= in command position, prefer the `functions' tag but use it with the name
functions-non-comp; anywhere you see that tag, exclude patterns matching
`_*) isn't particularly good, since the issue only really arises in command
position after you've typed a character, hence you really need
correction/approximation to test this, and it's hard to think of an
example.  I've borrowed this from the manual until I or someone else can
think of another clean, simple example.

Another thing:  I couldn't get matcher-list to work for a labelled
completer, e.g. _complete:-extended.  When I switched to matcher instead,
it worked fine.  This fit my preconception, when I eventually decided what
that would have been, because I though matcher-list was decided once right
at the start.  However, the manual explicitly says that you can use
matcher-list with labelled completers.

Tail-ender:  this is a real bug:
  % zsh -f
  % autoload -U compinit; compinit -D
  % zstyle ':completion:*' completer _expand _complete
  % zstyle ':<TAB>
           ^this gets replaced by an character from the upper end of
            ISO-8859-1 which I didn't particularly want to see.

The style subst-globs-only is several times referred to without the
plural, which is particularly annoying in _zstyle, but also occurs in the
doc.  (No patch, since it's almost half past midnight and I like to eat
this evening.)

This is probably known, but _next_tags doesn't work well with menu
completion.  Ideally, it should probably remove the current choice if the
last command was a menu completion and replace it with the first choice
from the list generated with the next tag.  Also, the message at the top
doesn't change; you still see `Completing TeX or LaTeX file' if you cycle
through to completing directories.  Maybe this is a feature.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk