Re PATCH _file_systems & Re zstyle for _arguments feature request

Re PATCH _file_systems & Re zstyle for _arguments feature request

[Oliver Kiddle]

Sven wrote:

> With this, I agreee with Oliver that this might indeed be the real
> problem, so I changed the implementation of `compadd -x'. Messages
> added with that still always show up, but otherwise they are now like
> the descriptions added with -X. Then I changed _message to accept the
> option `-e <tag> <descr>' which adds such a description for the given
> tag.

This looks good and seems to work well. I've also not found any
problems with the patches for the fake style and for function arguments
in compdef.

On the subject of the fake style, if we find that there is demand for
something more powerful, using _alternative like specs would probably
be sufficient though I'm not sure whether that could be made to work
because the functions need to be called from somewhere. Using zstyle -e
with the current fake style allows some fairly powerful things to be
done but there can be problems..

While I'm on the subject of recent patches, the man page sectioning
patch is great so thanks for that Sven. I only wonder that the
separate-sections style shouldn't be the default. For people who don't
like it, the group-name style can re-group them but is there any way to
have one description for the re-grouped sections.

> We would have to look through the functions using
> _message to see which of them should be changed to use `_message -e'.

Yes. I could do that if you don't want to but it would have to then
wait as I'm about to leave for a week of skiing in Austria.

> I've done this for _chown as an example (to show you how simple it

Note that the tag in this _chown change should be `options' instead
of `option'.

I have found one small thing which I don't think is right though:
  zstyle ':completion::complete:grep:argument-1:*' fake one two three
  grep x<tab>
Because x doesn't match one two or three, it is now not displaying the
message `pattern' but it isn't saying `No matches for <tag>' either.

Continuing to display `pattern' would perhaps be best because matches
added with fake are probably not an exhaustive set. There are
completion functions where we don't add an exhaustive set of matches
either. An example would be after vncserver -geometry (any x y
combination would be valid). Perhaps in these cases, by using -x
instead of -X, the message should persist instead of getting `No
matches for...'.

It would also be very useful in cases such as this in _cvs:
  if (( $#vendor_branch )); then
    _wanted values expl 'vendor branch' compadd -a vendor_branch
  else
    _message 'vendor branch'
  fi

_wanted would need to be modified to take the -x option which would
cause it (or _description) to change -X in expl to -x. _cvs would
then only need to do:

  _wanted -x values expl 'vendor branch' compadd -a vendor_branch

> would be), but there are other places. The utility and core functions
> should be ok with this patch, except for _guard, where I'm not sure.
> Maybe we have to give it an option to tell it if the description is
> supposed to be a only message or such a new description-without-matches
> thing.

Looking at where we've used _guard, it certainly needs to be able to
use the description-without-matches thing but whether _guard might ever
be used for a plain message, I'm not sure. I can't see why it ever
would. We could always add an option for that later if it is needed.

Oliver

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

Re: Re PATCH _file_systems & Re zstyle for _arguments feature request

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> On the subject of the fake style, if we find that there is demand for
> something more powerful, using _alternative like specs would probably
> be sufficient though I'm not sure whether that could be made to work
> because the functions need to be called from somewhere. Using zstyle -e
> with the current fake style allows some fairly powerful things to be
> done but there can be problems..

Yes, it's a first try at something that can be made very powerful
anyway.  Using _alternative there is dangerous (I think, I haven't
tried it), but the fake style can be made more powerful without that
and without much work.  We only need to wait for ideas.

> While I'm on the subject of recent patches, the man page sectioning
> patch is great so thanks for that Sven. I only wonder that the
> separate-sections style shouldn't be the default. For people who don't
> like it, the group-name style can re-group them but is there any way to
> have one description for the re-grouped sections.

You mean removing the separate-sections style?  I've added that
because I couldn't think of a way to get the other description (for
the case when the matches from all sections are shown together)
without adding it.  That would require some (probably serious) changes
to the group-name style, whose implementation is currently nicely
simple, so I was reluctant to even try that.  Is the solution with the
new style so ugly that we have to try?

> ...
> 
> > I've done this for _chown as an example (to show you how simple it
> 
> Note that the tag in this _chown change should be `options' instead
> of `option'.

Oops.  M-w no good ;-}  Thanks!

> I have found one small thing which I don't think is right though:
>   zstyle ':completion::complete:grep:argument-1:*' fake one two three
>   grep x<tab>
> Because x doesn't match one two or three, it is now not displaying the
> message `pattern' but it isn't saying `No matches for <tag>' either.

Oops, again.  Buglet in the C-code change, of course I wanted to
achieve:

> Continuing to display `pattern' would perhaps be best because matches
> added with fake are probably not an exhaustive set. There are
> completion functions where we don't add an exhaustive set of matches
> either. An example would be after vncserver -geometry (any x y
> combination would be valid). Perhaps in these cases, by using -x
> instead of -X, the message should persist instead of getting `No
> matches for...'.
> 
> It would also be very useful in cases such as this in _cvs:
>   if (( $#vendor_branch )); then
>     _wanted values expl 'vendor branch' compadd -a vendor_branch
>   else
>     _message 'vendor branch'
>   fi
> 
> _wanted would need to be modified to take the -x option which would
> cause it (or _description) to change -X in expl to -x. _cvs would
> then only need to do:
> 
>   _wanted -x values expl 'vendor branch' compadd -a vendor_branch

Good idea (although I'd probably take a different option letter there
(where function writers can see it)).  The patch below doens't contain
this, because we should then change _description and all the functions
that call it (not only _wanted), I'll look into this.

The patch also doesn't contain changes to other command-completion
functions because that should then probably wait until the changes to
_description and friends are in place.

> > would be), but there are other places. The utility and core functions
> > should be ok with this patch, except for _guard, where I'm not sure.
> > Maybe we have to give it an option to tell it if the description is
> > supposed to be a only message or such a new description-without-matches
> > thing.
> 
> Looking at where we've used _guard, it certainly needs to be able to
> use the description-without-matches thing but whether _guard might ever
> be used for a plain message, I'm not sure. I can't see why it ever
> would. We could always add an option for that later if it is needed.

Yes.  Problem is the way _guard is called -- we can't easily get at
the tag there (inside _guard) which would be needed to make sure the
description is attached to the same group of matches as the faked
matches (when the group-name style is used) -- otherwise the
description would be shown more than once.  I'll think about this some
more.


Felix Rosencrantz wrote:

> Though there is a possible strange behavior.  I'm not sure how multiple
> matches are handled in other situations, so this might just be how
> completion works.
> 
> Given these commands:
> 
> host@ zstyle :completion::complete:cvs-admin:option-k-1:option-k-1 fake
> b:binary
> host@ cvs admin -k<TAB>
> ---- keyword substitution
> b  -- binary
> b    k    kv   kvl  o    v
> 
> I wanted to add help text to options to the -k flag.  I was able to do that,
> however, "b" is now listed twice. (As well as any other options to which I
> add help.)

This is one of the cases where the faked matches end up in a different
group, similar to what I described above.  We'll work on this.

And this time, I'm going to commit it, makes my bookkeeping easier.


Bye
  Sven

Index: Completion/Base/Completer/_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_complete,v
retrieving revision 1.2
diff -u -r1.2 _complete
--- Completion/Base/Completer/_complete	2002/01/21 16:13:18	1.2
+++ Completion/Base/Completer/_complete	2002/01/22 10:20:39
@@ -36,7 +36,7 @@
 
     case "$action" in
     \ #)
-      _message "$descr";;
+      _message -e "$tag" "$descr";;
 
     \(\(*\)\))
       eval ws\=\( "${action[3,-3]}" \)
Index: Completion/Base/Core/_description
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_description,v
retrieving revision 1.2
diff -u -r1.2 _description
--- Completion/Base/Core/_description	2001/05/08 08:47:00	1.2
+++ Completion/Base/Core/_description	2002/01/22 10:20:39
@@ -1,6 +1,6 @@
 #autoload
 
-local name gropt=-J format gname hidden hide match opts
+local name gropt=-J format gname hidden hide match opts tag
 
 opts=()
 
@@ -51,6 +51,8 @@
   _comp_ignore=()
 fi
 
+tag="$1"
+
 shift 2
 if [[ -z "$1" && $# -eq 1 ]]; then
   format=
@@ -70,6 +72,17 @@
   else
     set -A "$name" "$opts[@]" "$gropt" -default-
   fi
+fi
+
+if ! (( ${funcstack[2,-1][(I)_description]} )) &&
+   zstyle -a ":completion:${curcontext}:$tag" fake match; then
+
+  local descr
+
+  descr=( "${(@M)match:#*[^\\]:*}" )
+
+  compadd "${(@P)name}" - "${(@)${(@)match:#*[^\\]:*}:s/\\:/:/}"
+  (( $#descr )) && _describe -t "$tag" '' descr "${(@P)name}"
 fi
 
 return 0
Index: Completion/Base/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_main_complete,v
retrieving revision 1.4
diff -u -r1.4 _main_complete
--- Completion/Base/Core/_main_complete	2001/08/17 10:37:00	1.4
+++ Completion/Base/Core/_main_complete	2002/01/22 10:20:40
@@ -268,7 +268,7 @@
       fi
     fi
   fi
-elif [[ nm -le 1 && -n "$_comp_mesg" ]]; then
+elif [[ nm -lt 1 && -n "$_comp_mesg" ]]; then
   compstate[insert]=''
   compstate[list]='list force'
 elif [[ nm -eq 0 && -z "$_comp_mesg" &&
Index: Completion/Base/Core/_message
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_message,v
retrieving revision 1.1
diff -u -r1.1 _message
--- Completion/Base/Core/_message	2001/04/02 11:03:34	1.1
+++ Completion/Base/Core/_message	2002/01/22 10:20:40
@@ -2,6 +2,19 @@
 
 local format raw
 
+if [[ "$1" = -e ]]; then
+  local expl ret=1
+
+  _comp_mesg=yes
+
+  _tags "$2" && while _next_label "$2" expl "$3"; do
+    compadd ${expl:/-X/-x}
+    ret=0
+  done
+
+  return ret
+fi
+
 _tags messages || return 1
 
 if [[ "$1" = -r ]]; then
Index: Completion/Base/Utility/_alternative
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_alternative,v
retrieving revision 1.1
diff -u -r1.1 _alternative
--- Completion/Base/Utility/_alternative	2001/04/02 11:12:39	1.1
+++ Completion/Base/Utility/_alternative	2002/01/22 10:20:40
@@ -31,7 +31,7 @@
 
         # An empty action means that we should just display a message.
 
-        mesgs=( "$mesgs[@]" "$descr")
+        mesgs=( "$mesgs[@]" "${def%%:*}:$descr")
       elif [[ "$action" = \(\(*\)\) ]]; then
         local ws
 
@@ -76,7 +76,7 @@
 done
 
 for descr in "$mesgs[@]"; do
-  _message "$descr"
+  _message -e "${descr%%:*}" "${desc#*:}"
 done
 
 return 1
Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.9
diff -u -r1.9 _arguments
--- Completion/Base/Utility/_arguments	2001/07/30 08:42:56	1.9
+++ Completion/Base/Utility/_arguments	2002/01/22 10:20:40
@@ -274,7 +274,7 @@
 
                 # An empty action means that we should just display a message.
 
-	        _message "$descr"
+	        _message -e "$subc" "$descr"
 	        mesg=yes
 	        tried=yes
                 alwopt=${alwopt:-yes}
Index: Completion/Base/Utility/_values
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_values,v
retrieving revision 1.6
diff -u -r1.6 _values
--- Completion/Base/Utility/_values	2001/06/13 11:05:51	1.6
+++ Completion/Base/Utility/_values	2002/01/22 10:20:40
@@ -103,7 +103,7 @@
 
       # An empty action means that we should just display a message.
 
-      _message "$descr"
+      _message -e arguments "$descr"
       return 1
 
     elif [[ "$action" = \(\(*\)\) ]]; then
Index: Completion/Unix/Command/_chown
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_chown,v
retrieving revision 1.5
diff -u -r1.5 _chown
--- Completion/Unix/Command/_chown	2002/01/03 12:47:56	1.5
+++ Completion/Unix/Command/_chown	2002/01/22 10:20:40
@@ -5,7 +5,7 @@
 line=( "${(@)words[2,CURRENT-1]:#-*}" )
 
 if [[ -prefix - ]]; then
-  _message option
+  _message -e options option
 elif [[ $#line -eq 0 ]]; then
   if [[ $service = chgrp ]] || compset -P '*[:.]'; then
     if (( EGID && $+commands[groups] )); then  # except for root
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.140
diff -u -r1.140 compsys.yo
--- Doc/Zsh/compsys.yo	2002/01/21 16:13:18	1.140
+++ Doc/Zsh/compsys.yo	2002/01/22 10:20:40
@@ -1120,6 +1120,22 @@
 this will also cycle through the names of the files in pathname
 components after the first ambiguous one.
 )
+kindex(fake, completion style)
+item(tt(fake))(
+This style may be set for every completion context and is used to
+specify additional strings to complete in that context.  It's values
+are either the strings to complete with every colon quoted by a
+preceding backslash or strings of the form
+`var(string)tt(:)var(description)'.  In the latter case the var(string)s
+will be shown together with the var(description)s in completion
+listings.
+
+Note that you only really want to use this style for a narrow
+enough context, so that the additional string won't show up in other
+contexts.  Also note the styles tt(fake-files) and tt(fake-parameters)
+which give more control over additional strings to add when completing
+files or parameters.
+)
 kindex(fake-files, completion style)
 item(tt(fake-files))(
 This style is used when completing files and looked up 
@@ -3676,7 +3692,8 @@
 followed by another character, only options are completed.
 )
 findex(_message)
-item(tt(_message) [ -r ] var(descr))(
+xitem(tt(_message) [ tt(-r) ] var(descr))
+item(tt(_message -e) var(tag descr))(
 The var(descr) is used like the third
 argument to the tt(_description) function. However, the resulting
 string will always be shown whether or not matches were
@@ -3691,6 +3708,10 @@
 used literally as the string to display. This is only used in cases
 where that string is taken from some pre-processed argument list
 containing an expanded description.
+
+In the second form, the var(descr) is added like a description added
+by tt(_description) under the given var(tag), but the var(descr) will
+always be shown even if no matches are added for the var(tag).
 )
 findex(_multi_parts)
 item(tt(_multi_parts) var(sep) var(array))(
Index: Src/Zle/comp.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/comp.h,v
retrieving revision 1.11
diff -u -r1.11 comp.h
--- Src/Zle/comp.h	2001/07/25 08:52:34	1.11
+++ Src/Zle/comp.h	2002/01/22 10:20:40
@@ -38,6 +38,7 @@
 /* This is for explantion strings. */
 
 struct cexpl {
+    int always;                 /* display even without matches */
     char *str;			/* the string */
     int count;			/* the number of matches */
     int fcount;			/* number of matches with fignore ignored */
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.52
diff -u -r1.52 compcore.c
--- Src/Zle/compcore.c	2002/01/07 14:43:40	1.52
+++ Src/Zle/compcore.c	2002/01/22 10:20:41
@@ -1618,6 +1618,18 @@
     Brinfo bp, bpl = brbeg, obpl, bsl = brend, obsl;
     Heap oldheap;
 
+    SWITCHHEAPS(oldheap, compheap) {
+        if (dat->mesg || dat->exp) {
+            curexpl = (Cexpl) zhalloc(sizeof(struct cexpl));
+            curexpl->always = !!dat->mesg;
+            curexpl->count = curexpl->fcount = 0;
+            curexpl->str = dupstring(dat->mesg ? dat->mesg : dat->exp);
+            if (dat->mesg)
+                addexpl(1);
+        } else
+            curexpl = NULL;
+    } SWITCHBACKHEAPS(oldheap);
+
     if (!*argv && !dat->dummies && !(dat->aflags & CAF_ALL)) {
 	SWITCHHEAPS(oldheap, compheap) {
 	    /* Select the group in which to store the matches. */
@@ -1631,8 +1643,6 @@
 		endcmgroup(NULL);
 		begcmgroup("default", 0);
 	    }
-	    if (dat->mesg)
-		addmesg(dat->mesg);
 	} SWITCHBACKHEAPS(oldheap);
 
 	return 1;
@@ -1689,13 +1699,6 @@
 		dparr = NULL;
 	    dparl = newlinklist();
 	}
-	if (dat->exp) {
-	    curexpl = (Cexpl) zhalloc(sizeof(struct cexpl));
-	    curexpl->count = curexpl->fcount = 0;
-	    curexpl->str = dupstring(dat->exp);
-	} else
-	    curexpl = NULL;
-
 	/* Store the matcher in our stack of matchers. */
 	if (dat->match) {
 	    mst.next = mstack;
@@ -1889,8 +1892,6 @@
 	    endcmgroup(NULL);
 	    begcmgroup("default", 0);
 	}
-	if (dat->mesg)
-	    addmesg(dat->mesg);
 	if (*argv) {
 	    if (dat->pre)
 		dat->pre = dupstring(dat->pre);
@@ -2057,7 +2058,7 @@
 	if (dat->dpar)
 	    set_list_array(dat->dpar, dparl);
 	if (dat->exp)
-	    addexpl();
+	    addexpl(0);
 	if (!hasallmatch && (dat->aflags & CAF_ALL)) {
             addmatch("<all>", dat->flags | CMF_ALL, &disp, 1);
 	    hasallmatch = 1;
@@ -2496,45 +2497,31 @@
 
 /**/
 mod_export void
-addexpl(void)
+addexpl(int always)
 {
     LinkNode n;
     Cexpl e;
 
     for (n = firstnode(expls); n; incnode(n)) {
 	e = (Cexpl) getdata(n);
-	if (e->count >= 0 && !strcmp(curexpl->str, e->str)) {
+	if (!strcmp(curexpl->str, e->str)) {
 	    e->count += curexpl->count;
 	    e->fcount += curexpl->fcount;
-
+            if (always) {
+                e->always = 1;
+                nmessages++;
+                newmatches = 1;
+                mgroup->new = 1;
+            }
 	    return;
 	}
     }
     addlinknode(expls, curexpl);
     newmatches = 1;
-}
-
-/* Add a message to the current group. Make sure it is shown. */
-
-/**/
-mod_export void
-addmesg(char *mesg)
-{
-    LinkNode n;
-    Cexpl e;
-
-    for (n = firstnode(expls); n; incnode(n)) {
-	e = (Cexpl) getdata(n);
-	if (e->count < 0 && !strcmp(mesg, e->str))
-	    return;
+    if (always) {
+        mgroup->new = 1;
+        nmessages++;
     }
-    e = (Cexpl) zhalloc(sizeof(*e));
-    e->count = e->fcount = -1;
-    e->str = dupstring(mesg);
-    addlinknode(expls, e);
-    newmatches = 1;
-    mgroup->new = 1;
-    nmessages++;
 }
 
 /* The comparison function for matches (used for sorting). */
@@ -2852,6 +2839,7 @@
 		for (eq = g->expls; (o = *eq); eq++, ep++) {
 		    *ep = e = (Cexpl) zcalloc(sizeof(struct cexpl));
 		    e->count = (fi ? o->fcount : o->count);
+                    e->always = o->always;
 		    e->fcount = 0;
 		    e->str = ztrdup(o->str);
 		}
Index: Src/Zle/compctl.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compctl.c,v
retrieving revision 1.11
diff -u -r1.11 compctl.c
--- Src/Zle/compctl.c	2001/11/28 18:30:51	1.11
+++ Src/Zle/compctl.c	2002/01/22 10:20:41
@@ -3808,9 +3808,9 @@
 	    if (cc->gname) {
 		endcmgroup(yaptr);
 		begcmgroup(cc->gname, gflags);
-		addexpl();
+		addexpl(0);
 	    } else {
-		addexpl();
+		addexpl(0);
 		endcmgroup(yaptr);
 		begcmgroup("default", 0);
 	    }
@@ -3825,7 +3825,7 @@
 	    untokenize(tt);
 	}
 	curexpl->str = tt;
-	addexpl();
+	addexpl(0);
     }
     if (cc->subcmd) {
 	/* Handle -l sub-completion. */
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.44
diff -u -r1.44 complist.c
--- Src/Zle/complist.c	2001/07/25 08:52:34	1.44
+++ Src/Zle/complist.c	2002/01/22 10:20:41
@@ -1042,9 +1042,9 @@
 		lastused = 1;
 	    }
 	    while (*e) {
-		if ((*e)->count &&
+		if (((*e)->count || (*e)->always) &&
 		    (!listdat.onlyexpl ||
-		     (listdat.onlyexpl & ((*e)->count > 0 ? 1 : 2)))) {
+		     (listdat.onlyexpl & ((*e)->always > 0 ? 2 : 1)))) {
 		    if (pnl) {
 			if (dolistnl(ml) && compprintnl(ml))
 			    goto end;
@@ -1058,8 +1058,9 @@
 		    }
 		    if (mlbeg < 0 && mfirstl < 0)
 			mfirstl = ml;
-		    l = compprintfmt((*e)->str, (*e)->count, dolist(ml), 1,
-				     ml, &stop);
+		    l = compprintfmt((*e)->str,
+                                     ((*e)->always ? -1 : (*e)->count),
+                                     dolist(ml), 1, ml, &stop);
 		    if (mselect >= 0) {
 			int mm = (mcols * ml), i;
 
Index: Src/Zle/compresult.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v
retrieving revision 1.42
diff -u -r1.42 compresult.c
--- Src/Zle/compresult.c	2001/10/05 12:44:01	1.42
+++ Src/Zle/compresult.c	2002/01/22 10:20:41
@@ -1494,10 +1494,12 @@
 	}
 	if ((e = g->expls)) {
 	    while (*e) {
-		if ((*e)->count &&
+		if (((*e)->count || (*e)->always) &&
 		    (!onlyexpl ||
-		     (onlyexpl & ((*e)->count > 0 ? 1 : 2))))
-		    nlines += 1 + printfmt((*e)->str, (*e)->count, 0, 1);
+		     (onlyexpl & ((*e)->always > 0 ? 2 : 1))))
+		    nlines += 1 + printfmt((*e)->str,
+                                           ((*e)->always ? -1 : (*e)->count),
+                                           0, 1);
 		e++;
 	    }
 	}
@@ -1840,9 +1842,9 @@
 	    int l;
 
 	    while (*e) {
-		if ((*e)->count &&
+		if (((*e)->count || (*e)->always) &&
 		    (!listdat.onlyexpl ||
-		     (listdat.onlyexpl & ((*e)->count > 0 ? 1 : 2)))) {
+		     (listdat.onlyexpl & ((*e)->always > 0 ? 2 : 1)))) {
 		    if (pnl) {
 			putc('\n', shout);
 			pnl = 0;
@@ -1853,7 +1855,8 @@
 				tcout(TCCLEAREOD);
 			}
 		    }
-		    l = printfmt((*e)->str, (*e)->count, 1, 1);
+		    l = printfmt((*e)->str,
+                                 ((*e)->always ? -1 : (*e)->count), 1, 1);
 		    ml += l;
 		    if (cl >= 0 && (cl -= l) <= 1) {
 			cl = -1;

-- 
Sven Wischnowsky                           wischnow@berkom.de

new fake style, completion grouping etc

[Oliver Kiddle]

Sven Wischnowsky wrote:

> Good idea (although I'd probably take a different option letter there
> (where function writers can see it)).  The patch below doens't contain
> this, because we should then change _description and all the functions
> that call it (not only _wanted), I'll look into this.

Yes, I realised it would need all the various _description calling
functions to take it. I'd prefer more of them to use zparseopts anyway
because it is easier to then read them.

> Yes.  Problem is the way _guard is called -- we can't easily get at
> the tag there (inside _guard) which would be needed to make sure the
> description is attached to the same group of matches as the faked
> matches (when the group-name style is used) -- otherwise the
> description would be shown more than once.  I'll think about this some
> more.

Argh. I can't think of anything better than _guard also needing to be
passed -e <tag>. Perhaps we should have _guard special cased as a form
of action in _arguments etc (despite my wish that _arguments were
simpler, utilising more separate functions). I'd have suggested
factoring out the action code from _arguments/_alternative etc if it
didn't mess up due to the internal tags use of the function stack.

Sven Wischnowsky wrote:
> 
> Felix Rosencrantz wrote:
> 
> > host@ zstyle :completion::complete:cvs-admin:option-k-1:option-k-1 fake
> > b:binary
> > host@ cvs admin -k<TAB>
> > ---- keyword substitution
> > b  -- binary
> > b    k    kv   kvl  o    v
> >
> I've had a closer look at this. It's because calling _describe adds
> the faked matches in a -V-group and later the normal matches are added
> in a -J-group.
> 
> Hrm.  Both showing -V- and -J-groups together or removing duplicates
> in such pairs of groups with the same name could mess things up
> terribly, so that's not a possible solution.

This is a hard one. It's a pity that the faked matches get added before
the real ones.

Searching through the completion system, I can't find any place where
we actually use both a sorted and unsorted group of matches together
with the same group-name. I realise it would be a big change but what I
would suggest would be to do away with the separate namespaces for
sorted and unsorted groups and just have a variable for each group to
identify the sorting style. This might then make it easy to have a
style which could change the sorting style for a particular group of
matches.

Backward compatibility wouldn't be too bad because we haven't really
ever mixed sorted/unsorted matches with the same group name. Though it
would be tempting to rename -J to -G, remove -V and have a -o taking
arguments to indicate sorted, unsorted, numeric ordering, sort by
description, a comparison function or whatever else. However I do
realise that with groups and sorting dating back to compctl this would
be no small change.

Sven wrote:

> You mean removing the separate-sections style?  I've added that
> because I couldn't think of a way to get the other description (for
> the case when the matches from all sections are shown together)
> without adding it.  That would require some (probably serious) changes
> to the group-name style, whose implementation is currently nicely
> simple, so I was reluctant to even try that.  Is the solution with the
> new style so ugly that we have to try?

I don't think it is so ugly, I just thought it would be better to have
a more generalised grouping style instead. I've never thought it ideal
that you still get several descriptions when you group several types of
matches together.

Sven Wischnowsky wrote:
> 
> > ./Y03arguments.ztst: test failed.
> 
> Grrrr... that's a result of the fake style patch. Previously, with a
> function containing:
> 
>   _argument '-x' ':arg:'
> 
> doing
> 
>   foo -<TAB>
> 
> didn't insert anything and displayed be message `arg'.

And it offered -x as a match (but not completing it) too right?

> This was done by some code in _main_complete which I had to change
> because otherwise adding completing a faked matched for the `arg'
> above wouldn't work. Quite naturally, actually.

The old behaviour seemed right to me but I don't entirely understand
why the fake style required the change. I'd have thought that any
description added with -x should potentially block other matches from
being completed with the _guard tactic being employed so that other
things get completed. This allows the lists of options to be displayed
though it might be useful if additional uses of the tab key allowed
completing of the options (menu selection doesn't seem to even work for
this case in 4.0.4).

Or am I misunderstanding this problem?

Oliver

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

Re: new fake style, completion grouping etc

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> > Yes.  Problem is the way _guard is called -- we can't easily get at
> > the tag there (inside _guard) which would be needed to make sure the
> > description is attached to the same group of matches as the faked
> > matches (when the group-name style is used) -- otherwise the
> > description would be shown more than once.  I'll think about this some
> > more.
> 
> Argh. I can't think of anything better than _guard also needing to be
> passed -e <tag>. Perhaps we should have _guard special cased as a form
> of action in _arguments etc (despite my wish that _arguments were
> simpler, utilising more separate functions). I'd have suggested
> factoring out the action code from _arguments/_alternative etc if it
> didn't mess up due to the internal tags use of the function stack.

But in the case of _arguments, the tag is created created
automatically, so the user couldn't know it (well, he could know it
beacuse we know how they are constructed, but...).

Maybe we should make _guard derive the name from the -[JV] argument,
that would be saver than it sounds (the group name is set from the
group-name style, which is tag for most people using it at all, and it
would ensure that the matches are really in the same group).

> ...
> 
> This is a hard one. It's a pity that the faked matches get added before
> the real ones.

Yes, I've wished for a way to add them at the same time, too. But
writing a `compadd' function to allow this is a bad idea, I think.

> Searching through the completion system, I can't find any place where
> we actually use both a sorted and unsorted group of matches together
> with the same group-name. I realise it would be a big change but what I
> would suggest would be to do away with the separate namespaces for
> sorted and unsorted groups and just have a variable for each group to
> identify the sorting style. This might then make it easy to have a
> style which could change the sorting style for a particular group of
> matches.

I've thought about this, too, several times, but didn't dare it yet.
Maybe we should just do it and make 4.1 the phase of completion code
cleanup.

This wouldn't really help in this case, though. Because _describe adds
the matches with -V to be able to get the right layout. If one of the
real matches gets added earlier, the list display will get messed up.

> ...
> 
> Sven Wischnowsky wrote:
> > 
> > > ./Y03arguments.ztst: test failed.
> > 
> > Grrrr... that's a result of the fake style patch. Previously, with a
> > function containing:
> > 
> >   _argument '-x' ':arg:'
> > 
> > doing
> > 
> >   foo -<TAB>
> > 
> > didn't insert anything and displayed be message `arg'.
> 
> And it offered -x as a match (but not completing it) too right?

Yes.

> > This was done by some code in _main_complete which I had to change
> > because otherwise adding completing a faked matched for the `arg'
> > above wouldn't work. Quite naturally, actually.
> 
> The old behaviour seemed right to me but I don't entirely understand
> why the fake style required the change.

If you added some fake matches and completed them everything worked
fine until there was only one string matches the stuff on the line
left. That one you couldn't complete.


Bye
  Sven

-- 
Sven Wischnowsky                           wischnow@berkom.de

Re: new fake style, completion grouping etc

[Oliver Kiddle]

 --- Sven Wischnowsky <wischnow@berkom.de> wrote:

> But in the case of _arguments, the tag is created created
> automatically, so the user couldn't know it (well, he could know it
> beacuse we know how they are constructed, but...).
> 
> Maybe we should make _guard derive the name from the -[JV] argument,
> that would be saver than it sounds (the group name is set from the
> group-name style, which is tag for most people using it at all, and
> it
> would ensure that the matches are really in the same group).

I'm not sure that I like the idea of using the group name - seems a bit
hacky. I'd be more inclined to make _arguments call _guard for some
special action syntax, e.g. :-/pattern/.

> I've thought about this, too, several times, but didn't dare it yet.
> Maybe we should just do it and make 4.1 the phase of completion code
> cleanup.
> 
> This wouldn't really help in this case, though. Because _describe
> adds
> the matches with -V to be able to get the right layout. If one of the
> real matches gets added earlier, the list display will get messed up.

Well, it would help in that all the matches would be together in the
same list under the same description. The fake matches would just not
be sorted so the layout might not be ideal.

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: new fake style, completion grouping etc

[Sven Wischnowsky]

Oliver Kiddle wrote:

>  --- Sven Wischnowsky <wischnow@berkom.de> wrote:
> 
> > But in the case of _arguments, the tag is created created
> > automatically, so the user couldn't know it (well, he could know it
> > beacuse we know how they are constructed, but...).
> > 
> > Maybe we should make _guard derive the name from the -[JV] argument,
> > that would be saver than it sounds (the group name is set from the
> > group-name style, which is tag for most people using it at all, and
> > it
> > would ensure that the matches are really in the same group).
> 
> I'm not sure that I like the idea of using the group name - seems a bit
> hacky. I'd be more inclined to make _arguments call _guard for some
> special action syntax, e.g. :-/pattern/.

That's why I didn't do it yet. Although I have a patch here with that
change and some others.

But...

> > I've thought about this, too, several times, but didn't dare it yet.
> > Maybe we should just do it and make 4.1 the phase of completion code
> > cleanup.
> > 
> > This wouldn't really help in this case, though. Because _describe
> > adds
> > the matches with -V to be able to get the right layout. If one of the
> > real matches gets added earlier, the list display will get messed up.
> 
> Well, it would help in that all the matches would be together in the
> same list under the same description. The fake matches would just not
> be sorted so the layout might not be ideal.

since I'm far from sure (actually, I doubt) we'll ever be able to
cleanly fix this, we should probably re-think this.

The problem isn't just that the layout might be `not ideal', it may
become completely messed up or without duplicates removed.

We could circumvent all these problems by just admitting it and make
faked matches be added under a different tag, i.e. in a different
group. With a default description of `faked matches' or a user
supplied one.

Would that be inacceptable?


Anyway, below is that patch (including a possible fix for the
_arguments-x thing we were discussing). Not to be committed right now.


Bye
  Sven

diff -ur -r ../oz/Completion/Base/Core/_all_labels ./Completion/Base/Core/_all_labels
--- ../oz/Completion/Base/Core/_all_labels	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Core/_all_labels	Mon Feb  4 22:20:29 2002
@@ -1,16 +1,14 @@
 #autoload
 
-local __gopt=-J __len __tmp __pre __suf __ret=1 __descr __spec __prev
+local __gopt __len __tmp __pre __suf __ret=1 __descr __spec __prev
 
 if [[ "$1" = - ]]; then
   __prev=-
   shift
 fi
 
-if [[ "$1" = -([12]|)[VJ] ]]; then
-  __gopt="$1"
-  shift
-fi
+__gopt=()
+zparseopts -D -a __gopt 1 2 V J x
 
 __tmp=${argv[(ib:4:)-]}
 __len=$#
@@ -29,12 +27,12 @@
   _comp_tags="$_comp_tags $__spec "
   if [[ "$curtag" = *[^\\]:* ]]; then
     zformat -f __descr "${curtag#*:}" "d:$3"
-    _description "$__gopt" "${curtag%:*}" "$2" "$__descr"
+    _description "$__gopt[@]" "${curtag%:*}" "$2" "$__descr"
     curtag="${curtag%:*}"
 
     "$4" "${(P@)2}" "${(@)argv[5,-1]}" && __ret=0
   else
-    _description "$__gopt" "$curtag" "$2" "$3"
+    _description "$__gopt[@]" "$curtag" "$2" "$3"
 
     "${(@)argv[4,__pre]}" "${(P@)2}" "${(@)argv[__suf,-1]}" && __ret=0
   fi
diff -ur -r ../oz/Completion/Base/Core/_description ./Completion/Base/Core/_description
--- ../oz/Completion/Base/Core/_description	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Core/_description	Mon Feb  4 22:20:33 2002
@@ -1,13 +1,13 @@
 #autoload
 
-local name gropt=-J format gname hidden hide match opts tag
+local name gropt nopt xopt format gname hidden hide match opts tag
 
 opts=()
 
-if [[ "$1" = -([12]|)[VJ] ]]; then
-  gropt="$1"
-  shift
-fi
+gropt=(-J)
+xopt=(-X)
+nopt=()
+zparseopts -K -D -a nopt 1 2 V=gropt J=gropt x=xopt
 
 3="${${3##[[:blank:]]#}%%[[:blank:]]#}"
 [[ -n "$3" ]] && _lastdescr=( "$_lastdescr[@]" "$3" )
@@ -62,15 +62,15 @@
 
 if [[ -n "$gname" ]]; then
   if [[ -n "$format" ]]; then
-    set -A "$name" "$opts[@]" "$gropt" "$gname" -X "$format"
+    set -A "$name" "$opts[@]" "$nopt[@]" "$gropt" "$gname" "$xopt" "$format"
   else
-    set -A "$name" "$opts[@]" "$gropt" "$gname"
+    set -A "$name" "$opts[@]" "$nopt[@]" "$gropt" "$gname"
   fi
 else
   if [[ -n "$format" ]]; then
-    set -A "$name" "$opts[@]" "$gropt" -default- -X "$format"
+    set -A "$name" "$opts[@]" "$nopt[@]" "$gropt" -default- "$xopt" "$format"
   else
-    set -A "$name" "$opts[@]" "$gropt" -default-
+    set -A "$name" "$opts[@]" "$nopt[@]" "$gropt" -default-
   fi
 fi
 
@@ -80,6 +80,8 @@
   local descr
 
   descr=( "${(@M)match:#*[^\\]:*}" )
+
+  _fake_contexts=( "$_fake_contexts[@]" ":completion:${curcontext}:$tag" )
 
   compadd "${(@P)name}" - "${(@)${(@)match:#*[^\\]:*}:s/\\:/:/}"
   (( $#descr )) && _describe -t "$tag" '' descr "${(@P)name}"
diff -ur -r ../oz/Completion/Base/Core/_main_complete ./Completion/Base/Core/_main_complete
--- ../oz/Completion/Base/Core/_main_complete	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Core/_main_complete	Mon Feb  4 20:04:20 2002
@@ -22,6 +22,7 @@
       _completers _completer _completer_num curtag _comp_force_list \
       _matchers _matcher _c_matcher _matcher_num _comp_tags _comp_mesg  \
       mesg str context state line opt_args val_args curcontext="$curcontext" \
+      _fake_contexts \
       _last_nmatches=-1 _last_menu_style _def_menu_style _menu_style sel \
       _saved_exact="${compstate[exact]}" \
       _saved_lastprompt="${compstate[last_prompt]}" \
@@ -75,6 +76,7 @@
 
                 )
 _last_menu_style=()
+_fake_contexts=()
 
 if zstyle -s ":completion:${curcontext}:default" list-prompt tmp; then
   LISTPROMPT="$tmp"
diff -ur -r ../oz/Completion/Base/Core/_message ./Completion/Base/Core/_message
--- ../oz/Completion/Base/Core/_message	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Core/_message	Mon Feb  4 20:13:03 2002
@@ -1,6 +1,6 @@
 #autoload
 
-local format raw
+local format raw grp
 
 if [[ "$1" = -e ]]; then
   local expl ret=1
@@ -12,9 +12,22 @@
     ret=0
   done
 
+  (( $_fake_contexts[(I):completion:${curcontext}:$2] )) ||
+      compstate[insert]=
+
   return ret
 fi
 
+if [[ $1 = -[JV]?* ]]; then
+  grp=( "$1" )
+  shift
+elif [[ $1 = -[JV]* ]]; then
+  grp=( "$1" "$2" )
+  shift 2
+else
+  grp=()
+fi
+
 _tags messages || return 1
 
 if [[ "$1" = -r ]]; then
@@ -28,6 +41,6 @@
 
 if [[ -n "$format$raw" ]]; then
   [[ -z "$raw" ]] && zformat -f format "$format" "d:$1" "${(@)argv[2,-1]}"
-  builtin compadd -x "$format"
+  builtin compadd "$grp[@]" -x "$format"
   _comp_mesg=yes
 fi
diff -ur -r ../oz/Completion/Base/Core/_next_label ./Completion/Base/Core/_next_label
--- ../oz/Completion/Base/Core/_next_label	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Core/_next_label	Mon Feb  4 22:20:19 2002
@@ -1,21 +1,19 @@
 #autoload
 
-local __gopt=-J __descr __spec
+local __gopt __descr __spec
 
-if [[ "$1" = -([12]|)[VJ] ]]; then
-  __gopt="$1"
-  shift
-fi
+__gopt=()
+zparseopts -D -a __gopt 1 2 V J x
 
 if comptags -A "$1" curtag __spec; then
   _comp_tags="$_comp_tags $__spec "
   if [[ "$curtag" = *[^\\]:* ]]; then
     zformat -f __descr "${curtag#*:}" "d:$3"
-    _description "$__gopt" "${curtag%:*}" "$2" "$__descr"
+    _description "$__gopt[@]" "${curtag%:*}" "$2" "$__descr"
     curtag="${curtag%:*}"
     set -A $2 "${(P@)2}" "${(@)argv[4,-1]}"
   else
-    _description "$__gopt" "$curtag" "$2" "$3"
+    _description "$__gopt[@]" "$curtag" "$2" "$3"
     set -A $2 "${(@)argv[4,-1]}" "${(P@)2}"
   fi
 
diff -ur -r ../oz/Completion/Base/Core/_requested ./Completion/Base/Core/_requested
--- ../oz/Completion/Base/Core/_requested	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Core/_requested	Mon Feb  4 22:20:14 2002
@@ -1,17 +1,15 @@
 #autoload
 
-local __gopt=-J
+local __gopt
 
-if [[ "$1" = -([12]|)[VJ] ]]; then
-  __gopt="$1"
-  shift
-fi
+__gopt=()
+zparseopts -D -a __gopt 1 2 V J x
 
 if comptags -R "$1"; then
   if [[ $# -gt 3 ]]; then
-    _all_labels - "$__gopt" "$@" || return 1
+    _all_labels - "$__gopt[@]" "$@" || return 1
   elif [[ $# -gt 1 ]]; then
-    _description "$__gopt" "$@"
+    _description "$__gopt[@]" "$@"
   fi
   return 0
 else
diff -ur -r ../oz/Completion/Base/Core/_wanted ./Completion/Base/Core/_wanted
--- ../oz/Completion/Base/Core/_wanted	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Core/_wanted	Mon Feb  4 22:20:51 2002
@@ -1,26 +1,15 @@
 #autoload
 
-local __targs __gopt=-J
+local __targs __gopt
 
-if [[ "$1" = -C?* ]]; then
-  __targs=( -C "${1[3,-1]}" )
-  shift
-elif [[ "$1" = -C ]]; then
-  __targs=( -C "$2" )
-  shift 2
-else
-  __targs=()
-fi
-
-if [[ "$1" = -([12]|)[VJ] ]]; then
-  __gopt="$1"
-  shift
-fi
+__gopt=()
+__tagrs=()
+zparseopts -D -a __gopt 1 2 V J x C:=__targs
 
 _tags "$__targs[@]" "$1"
 
 while _tags; do
-  _all_labels "$__gopt" "$@" && return 0
+  _all_labels "$__gopt[@]" "$@" && return 0
 done
 
 return 1
diff -ur -r ../oz/Completion/Base/Utility/_guard ./Completion/Base/Utility/_guard
--- ../oz/Completion/Base/Utility/_guard	Tue Jan 29 20:40:18 2002
+++ ./Completion/Base/Utility/_guard	Mon Feb  4 19:40:11 2002
@@ -1,17 +1,18 @@
 #autoload
 
-local mesg pat garbage
+local mesg grp pat garbage
 
 mesg=()
-zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg 
+grp=()
+zparseopts -K -D -a garbage M: J:=grp V:=grp 1 2 n F: X:=mesg 
 
 [[ "$PREFIX$SUFFIX" != $~1 ]] && return 1
 
 if [[ $# -gt 1 || $#mesg -eq 0 ]]; then
   shift
-  _message "$*"
+  _message "$grp[@]" "$*"
 else
-  _message -r "$mesg[2]"
+  _message "$grp[@]" -r "$mesg[2]"
 fi
 
 [[ -n "$PREFIX$SUFFIX" ]]
diff -ur -r ../oz/Doc/Zsh/compsys.yo ./Doc/Zsh/compsys.yo
--- ../oz/Doc/Zsh/compsys.yo	Tue Jan 29 20:40:18 2002
+++ ./Doc/Zsh/compsys.yo	Mon Feb  4 21:19:58 2002
@@ -3692,7 +3692,7 @@
 followed by another character, only options are completed.
 )
 findex(_message)
-xitem(tt(_message) [ tt(-r) ] var(descr))
+xitem(tt(_message) [ tt(-[JV]) var(group) ] [ tt(-r) ] var(descr))
 item(tt(_message -e) var(tag descr))(
 The var(descr) is used like the third
 argument to the tt(_description) function. However, the resulting
@@ -3708,6 +3708,9 @@
 used literally as the string to display. This is only used in cases
 where that string is taken from some pre-processed argument list
 containing an expanded description.
+
+If the tt(-V) or tt(-J) option is given, the var(descr) will be added
+to the named var(group).
 
 In the second form, the var(descr) is added like a description added
 by tt(_description) under the given var(tag), but the var(descr) will
diff -ur -r ../oz/Src/Zle/compcore.c ./Src/Zle/compcore.c
--- ../oz/Src/Zle/compcore.c	Tue Jan 29 20:40:18 2002
+++ ./Src/Zle/compcore.c	Mon Feb  4 20:00:08 2002
@@ -1619,6 +1619,17 @@
     Heap oldheap;
 
     SWITCHHEAPS(oldheap, compheap) {
+	/* Select the group in which to store the matches. */
+	gflags = (((dat->aflags & CAF_NOSORT ) ? CGF_NOSORT  : 0) |
+		  ((dat->aflags & CAF_UNIQALL) ? CGF_UNIQALL : 0) |
+		  ((dat->aflags & CAF_UNIQCON) ? CGF_UNIQCON : 0));
+	if (dat->group) {
+	    endcmgroup(NULL);
+	    begcmgroup(dat->group, gflags);
+	} else {
+	    endcmgroup(NULL);
+	    begcmgroup("default", 0);
+	}
         if (dat->mesg || dat->exp) {
             curexpl = (Cexpl) zhalloc(sizeof(struct cexpl));
             curexpl->always = !!dat->mesg;
@@ -1630,23 +1641,9 @@
             curexpl = NULL;
     } SWITCHBACKHEAPS(oldheap);
 
-    if (!*argv && !dat->dummies && !(dat->aflags & CAF_ALL)) {
-	SWITCHHEAPS(oldheap, compheap) {
-	    /* Select the group in which to store the matches. */
-	    gflags = (((dat->aflags & CAF_NOSORT ) ? CGF_NOSORT  : 0) |
-		      ((dat->aflags & CAF_UNIQALL) ? CGF_UNIQALL : 0) |
-		      ((dat->aflags & CAF_UNIQCON) ? CGF_UNIQCON : 0));
-	    if (dat->group) {
-		endcmgroup(NULL);
-		begcmgroup(dat->group, gflags);
-	    } else {
-		endcmgroup(NULL);
-		begcmgroup("default", 0);
-	    }
-	} SWITCHBACKHEAPS(oldheap);
-
+    if (!*argv && !dat->dummies && !(dat->aflags & CAF_ALL))
 	return 1;
-    }
+
     if (dat->dummies)
         dat->aflags = (dat->aflags | CAF_NOSORT | CAF_UNIQCON) & ~CAF_UNIQALL;
     for (bp = brbeg; bp; bp = bp->next)
@@ -1880,17 +1877,6 @@
 			haspattern = 1;
 		}
 	    }
-	}
-	/* Select the group in which to store the matches. */
-	gflags = (((dat->aflags & CAF_NOSORT ) ? CGF_NOSORT  : 0) |
-		  ((dat->aflags & CAF_UNIQALL) ? CGF_UNIQALL : 0) |
-		  ((dat->aflags & CAF_UNIQCON) ? CGF_UNIQCON : 0));
-	if (dat->group) {
-	    endcmgroup(NULL);
-	    begcmgroup(dat->group, gflags);
-	} else {
-	    endcmgroup(NULL);
-	    begcmgroup("default", 0);
 	}
 	if (*argv) {
 	    if (dat->pre)
diff -ur -r ../oz/Test/Y03arguments.ztst ./Test/Y03arguments.ztst
--- ../oz/Test/Y03arguments.ztst	Mon Feb  4 20:18:05 2002
+++ ./Test/Y03arguments.ztst	Mon Feb  4 20:19:02 2002
@@ -91,7 +91,7 @@
  comptest $'tst -\t'
 0:argument beginning with minus
 >line: {tst -}{}
->MESSAGE:{arg}
+>DESCRIPTION:{arg}
 >DESCRIPTION:{option}
 >NO:{-x}
 

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

Re: new fake style, completion grouping etc

[Oliver Kiddle]

Sven wrote:

> > I'm not sure that I like the idea of using the group name - seems a
bit
> > hacky. I'd be more inclined to make _arguments call _guard for some
> > special action syntax, e.g. :-/pattern/.
> 
> That's why I didn't do it yet.

I'm fairly convinced _guard needs to be using _message's -e so we need
something. If you do use the group name it should perhaps be well
commented in _guard though as it would otherwise confuse someone
someday.

> since I'm far from sure (actually, I doubt) we'll ever be able to
> cleanly fix this, we should probably re-think this.
> 
> The problem isn't just that the layout might be `not ideal', it may
> become completely messed up or without duplicates removed.

The only places we do anything special with the layout that I can think
of, it is purely to get a numerically sorted list. A compadd option for
numerically sorted groups as per my suggestion would handle that nicely
as the sorting only takes place after all matches, including fakes have
been added.

As far as I can tell, the only case where duplicates are removed is if
neither match has a description. I suppose the ideal would be for the
fake match to replace the normal match so as to potentially change it's
description. So with fake matches being added first, the first of a
duplicate could be kept within a group.

Do we ever want to have duplicates with the same description in a
group? And, do you know of any cases where the layout is anything other
than a sorted or numerically sorted list?

> We could circumvent all these problems by just admitting it and make
> faked matches be added under a different tag, i.e. in a different
> group. With a default description of `faked matches' or a user
> supplied one.
> 
> Would that be inacceptable?

To avoid all the problems (other than just layout, sorting issues), the
tag would have to be something totally separate like `faked'. To do
this would be a pity because in cases where there is more than one type
of match, we couldn't associate the fakes with either type. The result
would just be less seamless.

By using a different tag but deriving it from the real tag, e.g.
fake-users, we would only solve the layout problems. I don't think it
would be ideal though. I'd prefer to add fake matches as if they were
real ones.

> Anyway, below is that patch (including a possible fix for the
> _arguments-x thing we were discussing). Not to be committed right
now.

Looks good. I wasn't expecting the different behaviour for
f() { _wanted -x foos expl foo compadd } and
f() { _message -e foos foo }

The former gives both the description (foo) and the `No matches for'
message. This seems to be _message setting _comp_mesg. I don't think
the No matches for message is relevant when we are listing the foo
description so I think _description should also set _comp_mesg when
$xopt is -x.

I also think it might be a good idea to optionally allow a different
format string for -x descriptions - it'd just be another style lookup.

_arguments-x stuff looks fine but I only tested it briefly.

Oliver


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: new fake style, completion grouping etc

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> Sven wrote:
> 
> > > I'm not sure that I like the idea of using the group name - seems a
> bit
> > > hacky. I'd be more inclined to make _arguments call _guard for some
> > > special action syntax, e.g. :-/pattern/.
> > 
> > That's why I didn't do it yet.
> 
> I'm fairly convinced _guard needs to be using _message's -e so we need
> something.

I need to think some more then.

> ...
> 
> > since I'm far from sure (actually, I doubt) we'll ever be able to
> > cleanly fix this, we should probably re-think this.
> > 
> > The problem isn't just that the layout might be `not ideal', it may
> > become completely messed up or without duplicates removed.
> 
> The only places we do anything special with the layout that I can think
> of, it is purely to get a numerically sorted list. A compadd option for
> numerically sorted groups as per my suggestion would handle that nicely
> as the sorting only takes place after all matches, including fakes have
> been added.
> 
> As far as I can tell, the only case where duplicates are removed is if
> neither match has a description. I suppose the ideal would be for the
> fake match to replace the normal match so as to potentially change it's
> description. So with fake matches being added first, the first of a
> duplicate could be kept within a group.
> 
> Do we ever want to have duplicates with the same description in a
> group? And, do you know of any cases where the layout is anything other
> than a sorted or numerically sorted list?

Layout manipulation is at the core of _describe, used for options and
values, as in the cvs-admin-k-case we were discussing. It's what
allows the nicely aligned displays of options with the same
description. Those descriptions aren't added to the matches
themselves, they are basically added as separate string to be shown
and those strings have to be added together with the matches in just
the right order. That's why we need -V-groups there.

One solution would be to put some more work into lookup of the fake
style, i.e.: change some of our utility function to look it up
themselves so that they can correctly merge the faked matches into the
normal matches they are handling. _describe, probably _arguments and
others would be candidates for special treatment. for those we could
probably add an option to _description and friends meaning that the
fake style shouldn't be handled there.

Distributing lookup of the fake style over seeral functions isn't
nice, but the treatment in some functions is so special that it
probably allows exceptions. The stuff we have now would then be used
in normal cases where it should work good enough. And if the faked
matches stick out a bit in custom-sorted lists I'm not too concerned
(or at least think that a solution for this could be postponed until
we run into problems).

> ...
> 
> Looks good. I wasn't expecting the different behaviour for
> f() { _wanted -x foos expl foo compadd } and
> f() { _message -e foos foo }
> 
> The former gives both the description (foo) and the `No matches for'
> message. This seems to be _message setting _comp_mesg. I don't think
> the No matches for message is relevant when we are listing the foo
> description so I think _description should also set _comp_mesg when
> $xopt is -x.

Actually, I don't think so. The first one tells me that we try to
complete something but there are no matches, wheres in the second case
we only display a message, not trying to complete anything.

Another option? -s for `silent' or `-q' or something?

> I also think it might be a good idea to optionally allow a different
> format string for -x descriptions - it'd just be another style lookup.

Suggestions for a name? Looks like a relatively simple change, indeed.


Bye
  Sven

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

Re: new fake style, completion grouping etc

[Oliver Kiddle]

 --- Sven Wischnowsky <wischnow@berkom.de> wrote: > 

> Layout manipulation is at the core of _describe, used for options and

I need to have a closer look at what _describe is doing. I thought the
layout was more done in C.

> One solution would be to put some more work into lookup of the fake
> style, i.e.: change some of our utility function to look it up

Sounds like a reasonable possibility.

> > Looks good. I wasn't expecting the different behaviour for
> > f() { _wanted -x foos expl foo compadd } and
> > f() { _message -e foos foo }
> > 
> > The former gives both the description (foo) and the `No matches
> for'
> > message. This seems to be _message setting _comp_mesg. I don't
> think
> > the No matches for message is relevant when we are listing the foo
> > description so I think _description should also set _comp_mesg when
> > $xopt is -x.
> 
> Actually, I don't think so. The first one tells me that we try to
> complete something but there are no matches, wheres in the second
> case
> we only display a message, not trying to complete anything.

I disagree. Because _wanted has -x, I'd interpret it as
being that it possibly adds a few matches as a convenience but
is not adding all the possibilities. The _message is just a more
readable syntax for those cases where we haven't even attempted
to generate matches.

The void below the description communicates that the system is
unable to offer useful matches for the tag. The name of the tag
is the useful information and that is already displayed (in the
description). A "No matches for" message is useful as a way of
communicating tags which could go in the current context if any
possibilities matched. Perhaps, better phrasing would be
"No possible ".

My intention for -x was that it could be used wherever added
matches are not a complete list, e.g. hostname completion,
destination filename from the mv command.

> Another option? -s for `silent' or `-q' or something?

It isn't clear to me in what cases they would/wouldn't be used.
And I'd want them in every place where -x is.

> > I also think it might be a good idea to optionally allow a
> different
> > format string for -x descriptions - it'd just be another style
> lookup.

> Suggestions for a name? Looks like a relatively simple change,
> indeed.

If I'd been able to think of a good name, I might have done a patch
myself. The best I can think of is probably `held-descriptions'. I
can think of better words than `held' but they are all a bit long
resulting in a very long tag name. It should probably fall back on
whatever format is set for the `descriptions' tag. Actually, I think
the `descriptions' tag would be better named `heading' but I suppose
it is too late now.

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: new fake style, completion grouping etc

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> I'm fairly convinced _guard needs to be using _message's -e so we need
> something. If you do use the group name it should perhaps be well
> commented in _guard though as it would otherwise confuse someone
> someday.

Seems I've woken up. The functions handling tags set $curtag to
contain the name of the tag currently being completed. As long as all
functions are used in the right way, this should be entirely usable
inside _guard so we don't need to give it an extra argument.
Especially since _guard is only really intended to be used from
_arguments or similar functions.

Actually, I've made `_message -e' use $curtag if it is invoked with
only one argument (the message). This should make use of it even
simpler for many cases.

The patch also contains a cleanup-hunk for the C-code where I
accidentally left some code #if'ed out.

This patch does not move the lookup of the fake style into other
utility functions. Now that _guard seems to work I'm getting reluctant
to do that -- and for the case we were discussing (the cvs-admin-k-case)
it wouldn't help anyway because that problem was caused by the
fake-code calling _describe. I still don't know how this -[JV]-group-
thing can be cleanly solved. The patch also doesn't contain the change
to make _description use a differnet style name for -x-descriptions.


Bye
  Sven

Index: Completion/Base/Core/_message
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_message,v
retrieving revision 1.3
diff -u -r1.3 _message
--- Completion/Base/Core/_message	12 Feb 2002 13:37:04 -0000	1.3
+++ Completion/Base/Core/_message	25 Feb 2002 09:04:13 -0000
@@ -3,11 +3,17 @@
 local format raw gopt
 
 if [[ "$1" = -e ]]; then
-  local expl ret=1
+  local expl ret=1 tag
 
   _comp_mesg=yes
 
-  _tags "$2" && while _next_label "$2" expl "$3"; do
+  if (( $# > 2 )); then
+    tag="$2"
+    shift
+  else
+    tag="$curtag"
+  fi
+  _tags "$tag" && while _next_label "$tag" expl "$2"; do
     compadd ${expl:/-X/-x}
     ret=0
   done
Index: Completion/Base/Utility/_guard
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_guard,v
retrieving revision 1.1
diff -u -r1.1 _guard
--- Completion/Base/Utility/_guard	26 Apr 2001 12:13:37 -0000	1.1
+++ Completion/Base/Utility/_guard	25 Feb 2002 09:04:13 -0000
@@ -1,17 +1,12 @@
 #autoload
 
-local mesg pat garbage
+local garbage
 
-mesg=()
-zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg 
+zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:
 
 [[ "$PREFIX$SUFFIX" != $~1 ]] && return 1
 
-if [[ $# -gt 1 || $#mesg -eq 0 ]]; then
-  shift
-  _message "$*"
-else
-  _message -r "$mesg[2]"
-fi
+shift
+_message -e "$*"
 
 [[ -n "$PREFIX$SUFFIX" ]]
Index: Completion/Unix/Command/_grep
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_grep,v
retrieving revision 1.3
diff -u -r1.3 _grep
--- Completion/Unix/Command/_grep	6 Aug 2001 16:10:45 -0000	1.3
+++ Completion/Unix/Command/_grep	25 Feb 2002 09:04:13 -0000
@@ -51,7 +51,7 @@
   '(--null -Z --no-filename -h)'{--null,-Z}'[print 0 byte after FILE name]'
   '--help[display help]'
   '--mmap[memory map input]'
-  '(-e --regexp -f --file)1:pattern:_guard "^--*"'
+  '(-e --regexp -f --file)1: :_guard "^--*" pattern'
   '*:files:_files'
 )
 
Index: Completion/Unix/Command/_pbm
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_pbm,v
retrieving revision 1.3
diff -u -r1.3 _pbm
--- Completion/Unix/Command/_pbm	29 May 2001 17:54:37 -0000	1.3
+++ Completion/Unix/Command/_pbm	25 Feb 2002 09:04:13 -0000
@@ -398,7 +398,7 @@
     '-l-[specify left border width]:left border width:' \
     '-r-[specify right border width]:right border width:' \
     '-t-[specify top border width]:top border width:' \
-    '-b-[specify bottom border width]:bottom border width:_guard "[0-9]#"' \
+    '-b-[specify bottom border width]: :_guard "[0-9]#" "bottom border width"' \
     ':file: _pbm'
   ;;
 
Index: Completion/Unix/Command/_pine
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_pine,v
retrieving revision 1.5
diff -u -r1.5 _pine
--- Completion/Unix/Command/_pine	21 Feb 2002 06:00:58 -0000	1.5
+++ Completion/Unix/Command/_pine	25 Feb 2002 09:04:13 -0000
@@ -34,11 +34,11 @@
   "($opts $idx -url)-attach_and_delete[go to composer, attach file, delete when finished]:file:_files" \
   "($opts $idx $send)-url[open the given URL]:url:->url" \
   "($opts $send)-f+[specify mailbox to load]:mailbox: _mailboxes" \
-  "($opts $send)-c+[specify context to apply to -f arg]:number:_guard '[0-9]#'" \
+  "($opts $send)-c+[specify context to apply to -f arg]: :_guard '[0-9]#' number" \
   "($opts $send)-sort[specify sort order of folder]:sort order:(${(j: :)sortorder})" \
   "($opts $send)-i[go directly to index, bypassing main menu]" \
   "($opts $send)-I+[specify initial keystrokes to be executed]:keystrokes" \
-  "($opts $send)-n+[entry in index to begin on]:number:_guard '[0-9]#'" \
+  "($opts $send)-n+[entry in index to begin on]: :_guard '[0-9]#' number" \
   "($opts $send)-o[open first folder read-only]" \
   "(-F -h -v)-r[restricted - can only send mail to oneself]" \
   "(-h -v)-d[set debug level]:debug:(0 1 2 3 4 5 6 7 8 9 flush timestamp imap= numfiles= verbose=)" \
Index: Completion/X/Command/_vnc
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Command/_vnc,v
retrieving revision 1.4
diff -u -r1.4 _vnc
--- Completion/X/Command/_vnc	19 Dec 2001 15:10:40 -0000	1.4
+++ Completion/X/Command/_vnc	25 Feb 2002 09:04:13 -0000
@@ -13,7 +13,7 @@
 	'-geometry:geometry:(1600x1200 1280x1024 1152x864 1024x768 800x600 640x480)' \
 	'-depth:pixel depth:(8 16 24 32)' \
 	'-pixelformat:pixel format' \
-	'1::display number:_guard "(|:[0-9]#)"' \
+	'1:: :_guard "(|:[0-9]#)" "display number"' \
       - kill \
 	"-kill:display number:($displays)" \
       - help \
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.145
diff -u -r1.145 compsys.yo
--- Doc/Zsh/compsys.yo	18 Feb 2002 14:36:01 -0000	1.145
+++ Doc/Zsh/compsys.yo	25 Feb 2002 09:04:14 -0000
@@ -3673,7 +3673,7 @@
 be sure that the command understands the `tt(-)tt(-help)' option.
 )
 findex(_guard)
-item(tt(_guard) [ var(options) ] var(pattern) [ var(descr) ])(
+item(tt(_guard) [ var(options) ] var(pattern descr))(
 This function is intended to be used in an action of functions like
 tt(_arguments).  It returns immediately with a non-zero return value if
 the string to be completed does not match the var(pattern).  If the
@@ -3683,18 +3683,11 @@
 The var(pattern) may be preceded by those options understood by
 tt(compadd) that are passed down from tt(_description), namely tt(-M),
 tt(-J), tt(-V), tt(-1), tt(-2), tt(-n), tt(-F) and tt(-X).  All of these
-options, except tt(-X), will be ignored.  If the tt(-X) option appears,
-the description following it will be used as the string to display if
-the var(pattern) matches, unless the option var(descr) is given to
-tt(_guard) itself, which will then take precedence.
+options will be ignored.
 
 As an example, consider a command taking the options tt(-n) and
 tt(-none), where tt(-n) has to be followed by a numeric value in the
-same word.  By using either of:
-
-example(_argument '-n-:numeric value:_guard "[0-9]#"' '-none')
-
-or
+same word.  By using:
 
 example(_argument '-n-: :_guard "[0-9]#" "numeric value"' '-none')
 
@@ -3706,7 +3699,7 @@
 )
 findex(_message)
 xitem(tt(_message) [ tt(-r12) ] [ tt(-VJ) var(group) ] var(descr))
-item(tt(_message -e) var(tag descr))(
+item(tt(_message -e) [ var(tag) ] var(descr))(
 The var(descr) is used like the third
 argument to the tt(_description) function. However, the resulting
 string will always be shown whether or not matches were
@@ -3727,7 +3720,10 @@
 
 In the second form, the var(descr) is added like a description added
 by tt(_description) under the given var(tag), but the var(descr) will
-always be shown even if no matches are added for the var(tag).
+always be shown even if no matches are added for the var(tag).  If the
+var(tag) is omitted, it is taken from the tt(curtag) parameter which
+is set by the functions dealing with tags so it should contain the
+right one in almost all cases.
 )
 findex(_multi_parts)
 item(tt(_multi_parts) var(sep) var(array))(
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.54
diff -u -r1.54 compcore.c
--- Src/Zle/compcore.c	18 Feb 2002 14:30:47 -0000	1.54
+++ Src/Zle/compcore.c	25 Feb 2002 09:04:14 -0000
@@ -1648,10 +1648,6 @@
     if (!*argv && !dat->dummies && !(dat->aflags & CAF_ALL))
 	return 1;
 
-#if 0
-    if (dat->dummies)
-        dat->aflags = (dat->aflags | CAF_NOSORT | CAF_UNIQCON) & ~CAF_UNIQALL;
-#endif
     for (bp = brbeg; bp; bp = bp->next)
 	bp->curpos = ((dat->aflags & CAF_QUOTE) ? bp->pos : bp->qpos);
     for (bp = brend; bp; bp = bp->next)

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: new fake style, completion grouping etc

[Sven Wischnowsky]

I wrote:

> ...
> 
> Seems I've woken up. The functions handling tags set $curtag to
> contain the name of the tag currently being completed. As long as all
> functions are used in the right way, this should be entirely usable
> inside _guard so we don't need to give it an extra argument.
> Especially since _guard is only really intended to be used from
> _arguments or similar functions.

I forgot to point out that this means that _guard now has to be given
the description as an argument. It can't take it from an -X option it
gets anymore, see the (changed) docs, please.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de