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

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

[Felix Rosencrantz]

I tried it.  And there seems to be a bug, something seems to be called twice. I
added a fake style to enscript --font.  It seems like _description got called
twice.  Since the description was listed twice.  Also, to actually set the fake
style, I had two double the argument field twice.

Is there a way to remove an existing item?   So if completion would generate a
word, is way to have it not be listed/provided as an option.

Otherwise, it looks good to me, and I would say worthwhile.

-FR.

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> I tried it.  And there seems to be a bug, something seems to be called twice. I
> added a fake style to enscript --font.  It seems like _description got called
> twice.  Since the description was listed twice.  Also, to actually set the fake
> style, I had two double the argument field twice.

Err... pardon? ;-) Could you give us a code snippet to easily
reproduce this? I currently don't have that much time, sorry.

> Is there a way to remove an existing item?   So if completion would generate a
> word, is way to have it not be listed/provided as an option.

The ignored-patterns style?


Bye
  Sven

-- 
Sven Wischnowsky                           wischnow@berkom.de

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

[Felix Rosencrantz]

I really like the new fake parameter.

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


I'm happy with the new functionality.  Thanks Sven!  Since I'm already using
it,  I'd like to see that change committed.  :)

-FR.


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> I really like the new fake parameter.
> 
> 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.)

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.

Maybe I've got to re-think the whole fake-style thing again.


But anyway, the descriptions should be added by _cvs.


Bye
  Sven

-- 
Sven Wischnowsky                           wischnow@berkom.de

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

[Felix Rosencrantz]

Sven Wischnowsky wrote:
>Err... pardon? ;-) Could you give us a code snippet to easily
>reproduce this? I currently don't have that much time, sorry.

Sorry about that.  I'm writing from another system.
Here's something a little more specific.

I tried using the default completion for "enscript --font"

@ enscript --font []<TAB>
---- fontname
@ zstyle :completion::complete:enscript:option--font-1:option--font-1 fake
'font3:This is font3' font4:Four font5
@ enscript --font []<TAB>
---- fontname
---- fontname
<Then the correct font*'s are listed...>

Notice the "---fontname" description listed twice, and the need to specify the
"option--font-1" twice in the zstyle.  Something looks like it is being called
twice incorrectly.

-FR

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> Sven Wischnowsky wrote:
> >Err... pardon? ;-) Could you give us a code snippet to easily
> >reproduce this? I currently don't have that much time, sorry.
> 
> Sorry about that.  I'm writing from another system.
> Here's something a little more specific.
> 
> I tried using the default completion for "enscript --font"
> 
> @ enscript --font []<TAB>
> ---- fontname
> @ zstyle :completion::complete:enscript:option--font-1:option--font-1 fake
> 'font3:This is font3' font4:Four font5
> @ enscript --font []<TAB>
> ---- fontname
> ---- fontname
> <Then the correct font*'s are listed...>
> 
> Notice the "---fontname" description listed twice, and the need to specify the
> "option--font-1" twice in the zstyle.  Something looks like it is being called
> twice incorrectly.

Urgh.

1. The doubled `option-...' doesn't bother me a lot, that's just
   _arguments using the only sensible thing it knows about as the
   tag.  Users can always use `:completion:...:*'.
2. The doubled description is the real problem.  There is no action in
   the spec for --font.  So the faked matches get added under that
   default description mentioned above and later _arguments uses
   message to add the explanation it always adds for an empty action
   in a spec.  And that's the reason why the C code doesn't put the
   two groups together, which was irritating me before I looked.

Hrm.  I've got to think some more about this, or maybe someone else
has ideas?


Bye
  Sven

-- 
Sven Wischnowsky                           wischnow@berkom.de

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

[Oliver Kiddle]

I'm having problems with outgoing e-mail so sorry if this turns up
twice, in two weeks time, to Sven only or whatever.

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

> 2. The doubled description is the real problem.  There is no action
> in
>    the spec for --font.  So the faked matches get added under that
>    default description mentioned above and later _arguments uses
>    message to add the explanation it always adds for an empty action
>    in a spec.  And that's the reason why the C code doesn't put the
>    two groups together, which was irritating me before I looked.
> 
> Hrm.  I've got to think some more about this, or maybe someone else
> has ideas?

I mentioned before (14031, last two paragraphs) that using _message in
these cases also has the problem that the format style for the
descriptions tag is not looked up.

There needs to be a way to add a type of match with description but
without actually adding matches that can be used in those cases where
adding matches isn't sensible. The interface to it can perhaps be
_guard like for the pattern.

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: PATCH: _file_systems & Re: zstyle for _arguments feature request

[Sven Wischnowsky]

Oliver Kiddle wrote:

> I'm having problems with outgoing e-mail so sorry if this turns up
> twice, in two weeks time, to Sven only or whatever.
> 
> --- Sven Wischnowsky <wischnow@berkom.de> wrote: > 
> 
> > 2. The doubled description is the real problem.  There is no action
> > in
> >    the spec for --font.  So the faked matches get added under that
> >    default description mentioned above and later _arguments uses
> >    message to add the explanation it always adds for an empty action
> >    in a spec.  And that's the reason why the C code doesn't put the
> >    two groups together, which was irritating me before I looked.
> > 
> > Hrm.  I've got to think some more about this, or maybe someone else
> > has ideas?
> 
> I mentioned before (14031, last two paragraphs) that using _message in
> these cases also has the problem that the format style for the
> descriptions tag is not looked up.
> 
> There needs to be a way to add a type of match with description but
> without actually adding matches that can be used in those cases where
> adding matches isn't sensible. The interface to it can perhaps be
> _guard like for the pattern.

This took some time because I'm currently very busy here, but below is
a suggested patch.

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.

I'm still not going to commit this patch until I get positive replies,
but maybe it's already near enough to put it into the current
development version. We would have to look through the functions using
_message to see which of them should be changed to use `_message -e'.
I've done this for _chown as an example (to show you how simple it
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.


Bye
  Sven

diff -ur -r ../oz/Completion/Base/Completer/_complete ./Completion/Base/Completer/_complete
--- ../oz/Completion/Base/Completer/_complete	Thu Jan 17 19:49:32 2002
+++ ./Completion/Base/Completer/_complete	Thu Jan 17 22:22:56 2002
@@ -36,7 +36,7 @@
 
     case "$action" in
     \ #)
-      _message "$descr";;
+      _message -e "$tag" "$descr";;
 
     \(\(*\)\))
       eval ws\=\( "${action[3,-3]}" \)
diff -ur -r ../oz/Completion/Base/Core/_message ./Completion/Base/Core/_message
--- ../oz/Completion/Base/Core/_message	Thu Jan 17 19:49:32 2002
+++ ./Completion/Base/Core/_message	Thu Jan 17 22:52:13 2002
@@ -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
diff -ur -r ../oz/Completion/Base/Utility/_alternative ./Completion/Base/Utility/_alternative
--- ../oz/Completion/Base/Utility/_alternative	Thu Jan 17 19:49:32 2002
+++ ./Completion/Base/Utility/_alternative	Thu Jan 17 22:22:32 2002
@@ -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
diff -ur -r ../oz/Completion/Base/Utility/_arguments ./Completion/Base/Utility/_arguments
--- ../oz/Completion/Base/Utility/_arguments	Thu Jan 17 19:49:32 2002
+++ ./Completion/Base/Utility/_arguments	Thu Jan 17 22:12:54 2002
@@ -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}
diff -ur -r ../oz/Completion/Base/Utility/_values ./Completion/Base/Utility/_values
--- ../oz/Completion/Base/Utility/_values	Thu Jan 17 19:49:32 2002
+++ ./Completion/Base/Utility/_values	Thu Jan 17 23:07:30 2002
@@ -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
diff -ur -r ../oz/Completion/Unix/Command/_chown ./Completion/Unix/Command/_chown
--- ../oz/Completion/Unix/Command/_chown	Thu Jan 17 19:49:32 2002
+++ ./Completion/Unix/Command/_chown	Thu Jan 17 23:08:26 2002
@@ -5,7 +5,7 @@
 line=( "${(@)words[2,CURRENT-1]:#-*}" )
 
 if [[ -prefix - ]]; then
-  _message option
+  _message -e option option
 elif [[ $#line -eq 0 ]]; then
   if [[ $service = chgrp ]] || compset -P '*[:.]'; then
     if (( EGID && $+commands[groups] )); then  # except for root
diff -ur -r ../oz/Doc/Zsh/compsys.yo ./Doc/Zsh/compsys.yo
--- ../oz/Doc/Zsh/compsys.yo	Thu Jan 17 19:49:30 2002
+++ ./Doc/Zsh/compsys.yo	Thu Jan 17 23:16:07 2002
@@ -3679,7 +3679,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
@@ -3694,6 +3695,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))(
diff -ur -r ../oz/Src/Zle/comp.h ./Src/Zle/comp.h
--- ../oz/Src/Zle/comp.h	Thu Jan 17 19:49:31 2002
+++ ./Src/Zle/comp.h	Thu Jan 17 20:30:20 2002
@@ -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 */
diff -ur -r ../oz/Src/Zle/compcore.c ./Src/Zle/compcore.c
--- ../oz/Src/Zle/compcore.c	Thu Jan 17 19:49:31 2002
+++ ./Src/Zle/compcore.c	Thu Jan 17 21:22:30 2002
@@ -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,27 @@
 
 /**/
 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;
 	    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 +2835,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);
 		}
diff -ur -r ../oz/Src/Zle/compctl.c ./Src/Zle/compctl.c
--- ../oz/Src/Zle/compctl.c	Thu Jan 17 19:49:31 2002
+++ ./Src/Zle/compctl.c	Thu Jan 17 20:55:02 2002
@@ -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. */
diff -ur -r ../oz/Src/Zle/complist.c ./Src/Zle/complist.c
--- ../oz/Src/Zle/complist.c	Thu Jan 17 19:49:31 2002
+++ ./Src/Zle/complist.c	Thu Jan 17 20:59:56 2002
@@ -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;
 
diff -ur -r ../oz/Src/Zle/compresult.c ./Src/Zle/compresult.c
--- ../oz/Src/Zle/compresult.c	Thu Jan 17 19:49:31 2002
+++ ./Src/Zle/compresult.c	Thu Jan 17 21:02:12 2002
@@ -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

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

[Wischnowsky, Sven]

Oliver wrote:

> ...
> 
> You mean ignored-patterns right?

Ahem, right :-}

> ...
> 
> I suggest we just try something and see how it goes. Locating it in
> _description might work, assuming that the tag is in the 
context when
> the style is looked up. It might be a bit strange where 
more than one
> compadd is used to add matches.

Yes.

> ...
> 
> I'm not sure I like that much. We'd just end up with a 
style syntax for
> _generic growing into a compctl like thing. And, we'd find ourself
> having to graft much of this syntax onto every function.

Yes, that's what I want to avoid.

> Another method that might make things a little easier for 
> user's unsure
> about writing whole functions would be to allow simple one line
> completions to be defined thusly:
> 
> compdef '_files -g "*.c"' lcc
> compdef 'compadd one two three' count
> 
> It might be generally useful to allow arguments in the values of
> _comps anyway.

I quite like that idea, doesn't look too hard to implement (that's
me, trying to go through the completion system code in my brain,
sitting in front of this Windows box; but the linux install on my
new machine will be done in a few minutes and then I only need the
network patched and a cable to not feel castrated anymore ;-).

Bye
  Sven

PATCH: _file_systems & Re: zstyle for _arguments feature request

[Oliver Kiddle]

[-- Attachment #1: Type: text/plain, Size: 3377 bytes --]

Sven wrote:

> Felix wrote:
> > I think that would be ok.  Though it would also be nice to remove
> > some|all entries from the list being provided to the user.  Also,
> > it would be nice to provide help text for items.  I don't think
> > that can be currently done with the fake-* styles.
> 
> Erm, the ignored-matches style?

You mean ignored-patterns right?

> About the general fake style: I'm not sure where the compadd for it
> could be put. Probably in _setup or _description (where we have all
> the information about groups and so on), but there might be cases
> where the matches are then added more than once or into a group which
> isn't really used for matches (if the user doesn't give  near enogh
> context). Doing it with help texts further complicates this, of
> course. Especially if we want to have nice consistent listings
> because only the completion function decides if the normal matches
> get descriptions. We would just have to try it, I think.

I suggest we just try something and see how it goes. Locating it in
_description might work, assuming that the tag is in the context when
the style is looked up. It might be a bit strange where more than one
compadd is used to add matches.

> > I find that I want to use code
> > from the "state" actions of existing completion functions a lot.
> > It's not possible.
> 
> I've recommended that several times, although mostly because it makes
> writing functions easier (the main functions, using _arguments).

Yes, it is a good recommendation.

Patch to factor out a new _file_systems is below. The old _mount wasn't
even completing after umount -t so I'll apply this to 4.0 too.

> > >We should be careful how we document this. It should be a way of
> > >tweaking available completions to fake extra matches and should
not
> > >be a substitute for writing functions.
> > 
> > This is the sort of feedback I was interested in.  Though, it's not
> > clear to me why a completion function is better. 
> 
> My personal reason would be that I'd want to not fall into the
> compctl- trap again.

I'd agree with that reason.

> Yes, leaving the work for the users that have to set the styles (and
> if we are talking about those things I thik we are talking about,
> then there wouldn't be any defaults we could use for the styles). It
> might make sense to write some generic completer using lots of styles
> so that people have a way to `easily' create completions of their
> own, but I doubt it would be much easier than writing a little
> function, especially if the completion has to do anything useful. And
> how would that completer differ from _generic? Maybe we could just
> improve that one...

I'm not sure I like that much. We'd just end up with a style syntax for
_generic growing into a compctl like thing. And, we'd find ourself
having to graft much of this syntax onto every function.

Another method that might make things a little easier for user's unsure
about writing whole functions would be to allow simple one line
completions to be defined thusly:

compdef '_files -g "*.c"' lcc
compdef 'compadd one two three' count

It might be generally useful to allow arguments in the values of
_comps anyway.

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

[-- Attachment #2: fs.dif --]
[-- Type: application/x-unknown, Size: 9457 bytes --]

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

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> > About the general fake style: I'm not sure where the compadd for it
> > could be put. Probably in _setup or _description (where we have all
> > the information about groups and so on), but there might be cases
> > where the matches are then added more than once or into a group which
> > isn't really used for matches (if the user doesn't give  near enogh
> > context). Doing it with help texts further complicates this, of
> > course. Especially if we want to have nice consistent listings
> > because only the completion function decides if the normal matches
> > get descriptions. We would just have to try it, I think.
> 
> I suggest we just try something and see how it goes. Locating it in
> _description might work, assuming that the tag is in the context when
> the style is looked up. It might be a bit strange where more than one
> compadd is used to add matches.

Here is something to play with. It adds the `fake' style, tested in
_description. Still very basic, but matches with descriptions can be
added. I'm not going to commit this until I get positive replies.


Bye
  Sven

diff -ur ../oz/Completion/Base/Core/_description ./Completion/Base/Core/_description
--- ../oz/Completion/Base/Core/_description	Sun Dec 23 17:20:30 2001
+++ ./Completion/Base/Core/_description	Sun Dec 23 17:46:28 2001
@@ -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
diff -ur ../oz/Doc/Zsh/compsys.yo ./Doc/Zsh/compsys.yo
--- ../oz/Doc/Zsh/compsys.yo	Sun Dec 23 17:20:30 2001
+++ ./Doc/Zsh/compsys.yo	Sun Dec 23 17:51:18 2001
@@ -1082,6 +1082,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 

-- 
Sven Wischnowsky                           wischnow@berkom.de

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

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> Another method that might make things a little easier for user's unsure
> about writing whole functions would be to allow simple one line
> completions to be defined thusly:
> 
> compdef '_files -g "*.c"' lcc
> compdef 'compadd one two three' count
> 
> It might be generally useful to allow arguments in the values of
> _comps anyway.

And here is a patch for this. Not very nice, because we use $_comps in
several places and I've just added `eval's there. Probably should be
put into a separate function, but somehow it looks to small and simple
for that.

This, too, I'm not going to commit until I get replies.

Bye
  Sven

diff -ur ../oz/Completion/Base/Completer/_complete ./Completion/Base/Completer/_complete
--- ../oz/Completion/Base/Completer/_complete	Sun Dec 23 17:51:42 2001
+++ ./Completion/Base/Completer/_complete	Sun Dec 23 18:01:15 2001
@@ -85,7 +85,7 @@
     ccarray[3]="$compcontext"
 
     comp="$_comps[$compcontext]"
-    [[ -z "$comp" ]] || "$comp"
+    [[ -z "$comp" ]] || eval "$comp"
   fi
 
   return
@@ -97,7 +97,7 @@
 if [[ ! -z "$comp" ]]; then
   service="${_services[-first-]:--first-}"
   ccarray[3]=-first-
-  "$comp" && ret=0
+  eval "$comp" && ret=0
   if [[ "$_compskip" = all ]]; then
     _compskip=
     return ret
@@ -136,7 +136,7 @@
     comp="$_comps[-default-]"
   fi
   [[ -z "$comp" ]] ||
-      service="${_services[-default-]:--default-}" && "$comp" && ret=0
+      service="${_services[-default-]:--default-}" && eval "$comp" && ret=0
 fi
 
 _compskip=
diff -ur ../oz/Completion/Base/Core/_normal ./Completion/Base/Core/_normal
--- ../oz/Completion/Base/Core/_normal	Sun Dec 23 17:51:42 2001
+++ ./Completion/Base/Core/_normal	Sun Dec 23 17:59:46 2001
@@ -19,7 +19,7 @@
   curcontext="${curcontext%:*:*}:-command-:"
 
   comp="$_comps[-command-]"
-  [[ -z "$comp" ]] || "$comp" && ret=0
+  [[ -z "$comp" ]] || eval "$comp" && ret=0
 
   return ret
 else
@@ -86,7 +86,7 @@
 
 if [[ -n "$comp" ]]; then
   _compskip=patterns
-  "$comp" && ret=0
+  eval "$comp" && ret=0
   [[ "$_compskip" = (all|*patterns*) ]] && return ret
 elif [[ "$_compskip" != *default* ]]; then
   name=-default-
@@ -121,7 +121,7 @@
 fi
 
 [[ "$name" = -default- && -n "$comp" && "$_compskip" != (all|*default*) ]] &&
-  service="${_services[-default-]:--default-}" && "$comp" && ret=0
+  service="${_services[-default-]:--default-}" && eval "$comp" && ret=0
 
 _compskip=''
 
diff -ur ../oz/Completion/Base/Utility/_contexts ./Completion/Base/Utility/_contexts
--- ../oz/Completion/Base/Utility/_contexts	Sun Dec 23 17:51:42 2001
+++ ./Completion/Base/Utility/_contexts	Sun Dec 23 18:01:38 2001
@@ -11,7 +11,7 @@
 
 for i; do
   tmp="$_comps[$i]"
-  [[ -z "$tmp" ]] || service="${_services[$i]:-$i}" && "$tmp" && ret=0
+  [[ -z "$tmp" ]] || service="${_services[$i]:-$i}" && eval "$tmp" && ret=0
 done
 
 return ret
diff -ur ../oz/Completion/Unix/Command/_su ./Completion/Unix/Command/_su
--- ../oz/Completion/Unix/Command/_su	Sun Dec 23 17:51:42 2001
+++ ./Completion/Unix/Command/_su	Sun Dec 23 18:02:09 2001
@@ -18,5 +18,5 @@
 compset -n $base
 for name in $shell $shell:t -default-; do
   comp="$_comps[$name]"
-  [[ -n "$comp" ]] && "$comp" && return
+  [[ -n "$comp" ]] && eval "$comp" && return
 done  
diff -ur ../oz/Doc/Zsh/compsys.yo ./Doc/Zsh/compsys.yo
--- ../oz/Doc/Zsh/compsys.yo	Sun Dec 23 17:51:42 2001
+++ ./Doc/Zsh/compsys.yo	Sun Dec 23 18:26:46 2001
@@ -270,6 +270,15 @@
 `var(cmd)tt(=)var(service)'.  This kind of use makes the arguments of
 the var(cmd)s be completed as those for the var(services).
 
+In the first case and the following cases the var(function) may actually
+be a string containing any shell code and that string will be executed
+via the tt(eval) builtin command.  This allows to easily define completions
+for commands that need to call one of the completion functions with
+arguments.  For example to make files ending in `tt(.h)' be completed as
+arguments to the command tt(foo), one would use:
+
+example(compdef '_files -g "*.h"' foo)
+
 If the
 tt(-n) option is given, any existing completion behaviour for particular
 contexts or commands will not be altered.  These definitions can be deleted

-- 
Sven Wischnowsky                           wischnow@berkom.de

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

[Oliver Kiddle]

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

> And here is a patch for this. Not very nice, because we use $_comps
> in several places and I've just added `eval's there. Probably should
> be put into a separate function, but somehow it looks to small and
> simple for that.

It could be useful as a utility function anyway though. That it would
be used in _su convinces me. Including the $service setting stuff would
make it slightly less small. Perhaps it could be merged with _contexts
which is similar anyway.

> This, too, I'm not going to commit until I get replies.

It looks good to me and seems to work well. Using eval instead of $=tmp
is not something I'd thought about. I suppose it might be useful to get
at one of the special variables like $words or $QIPREFIX.

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: PATCH: _file_systems & Re: zstyle for _arguments feature request

[Sven Wischnowsky]

Oliver Kiddle wrote:

>  --- Sven Wischnowsky <wischnow@berkom.de> wrote: > 
> 
> > And here is a patch for this. Not very nice, because we use $_comps
> > in several places and I've just added `eval's there. Probably should
> > be put into a separate function, but somehow it looks to small and
> > simple for that.
> 
> It could be useful as a utility function anyway though. That it would
> be used in _su convinces me. Including the $service setting stuff would
> make it slightly less small. Perhaps it could be merged with _contexts
> which is similar anyway.
> 
> > This, too, I'm not going to commit until I get replies.
> 
> It looks good to me and seems to work well. Using eval instead of $=tmp
> is not something I'd thought about. I suppose it might be useful to get
> at one of the special variables like $words or $QIPREFIX.

Here is a better patch and I'm going to commit it this time.

I've left the calls to `eval' in _complete and _normal, these
functions are just too specialised to put that code into a separate
function (and they are part of the core system anyway).  For _su I've
given _contexts an option (-o) that makes the contexts be or'ed, i.e.
_contexts returns as soon as completions could be generated for one of
the contexts.

Bye
  Sven

Index: Completion/Base/Completer/_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_complete,v
retrieving revision 1.1
diff -u -r1.1 _complete
--- Completion/Base/Completer/_complete	2001/04/02 11:06:01	1.1
+++ Completion/Base/Completer/_complete	2002/01/21 16:03:55
@@ -85,7 +85,7 @@
     ccarray[3]="$compcontext"
 
     comp="$_comps[$compcontext]"
-    [[ -z "$comp" ]] || "$comp"
+    [[ -n "$comp" ]] && eval "$comp"
   fi
 
   return
@@ -94,10 +94,10 @@
 # An entry for `-first-' is the replacement for `compctl -T'
 
 comp="$_comps[-first-]"
-if [[ ! -z "$comp" ]]; then
+if [[ -n "$comp" ]]; then
   service="${_services[-first-]:--first-}"
   ccarray[3]=-first-
-  "$comp" && ret=0
+  eval "$comp" && ret=0
   if [[ "$_compskip" = all ]]; then
     _compskip=
     return ret
@@ -135,8 +135,8 @@
     fi
     comp="$_comps[-default-]"
   fi
-  [[ -z "$comp" ]] ||
-      service="${_services[-default-]:--default-}" && "$comp" && ret=0
+  [[ -n "$comp" ]] &&
+      service="${_services[-default-]:--default-}" && eval "$comp" && ret=0
 fi
 
 _compskip=
Index: Completion/Base/Core/_normal
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_normal,v
retrieving revision 1.1
diff -u -r1.1 _normal
--- Completion/Base/Core/_normal	2001/04/02 11:04:04	1.1
+++ Completion/Base/Core/_normal	2002/01/21 16:03:55
@@ -19,7 +19,7 @@
   curcontext="${curcontext%:*:*}:-command-:"
 
   comp="$_comps[-command-]"
-  [[ -z "$comp" ]] || "$comp" && ret=0
+  [[ -n "$comp" ]] && eval "$comp" && ret=0
 
   return ret
 else
@@ -86,7 +86,7 @@
 
 if [[ -n "$comp" ]]; then
   _compskip=patterns
-  "$comp" && ret=0
+  eval "$comp" && ret=0
   [[ "$_compskip" = (all|*patterns*) ]] && return ret
 elif [[ "$_compskip" != *default* ]]; then
   name=-default-
@@ -121,7 +121,7 @@
 fi
 
 [[ "$name" = -default- && -n "$comp" && "$_compskip" != (all|*default*) ]] &&
-  service="${_services[-default-]:--default-}" && "$comp" && ret=0
+  service="${_services[-default-]:--default-}" && eval "$comp" && ret=0
 
 _compskip=''
 
Index: Completion/Base/Utility/_contexts
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_contexts,v
retrieving revision 1.1
diff -u -r1.1 _contexts
--- Completion/Base/Utility/_contexts	2001/04/02 11:10:27	1.1
+++ Completion/Base/Utility/_contexts	2002/01/21 16:03:55
@@ -7,11 +7,17 @@
 # `_contexts -math-' to get the completions that would be generated for a
 # mathematical context.
 
-local i tmp ret=1 service
+local i tmp ret=1 service or
 
+if [[ $1 = -o ]]; then
+  or=yes
+  shift
+fi
+
 for i; do
   tmp="$_comps[$i]"
-  [[ -z "$tmp" ]] || service="${_services[$i]:-$i}" && "$tmp" && ret=0
+  [[ -n "$tmp" ]] && service="${_services[$i]:-$i}" && eval "$tmp" && ret=0
+  [[ -n "$or" && ret -eq 0 ]] && return 0
 done
 
 return ret
Index: Completion/Unix/Command/_su
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_su,v
retrieving revision 1.1
diff -u -r1.1 _su
--- Completion/Unix/Command/_su	2001/04/02 12:03:16	1.1
+++ Completion/Unix/Command/_su	2002/01/21 16:03:55
@@ -16,7 +16,5 @@
 
 shell="${${(M@)${(@f)$(</etc/passwd)}:#$usr*}##*:}"
 compset -n $base
-for name in $shell $shell:t -default-; do
-  comp="$_comps[$name]"
-  [[ -n "$comp" ]] && "$comp" && return
-done  
+
+_contexts -o $shell $shell:t -default-
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.139
diff -u -r1.139 compsys.yo
--- Doc/Zsh/compsys.yo	2002/01/10 11:00:05	1.139
+++ Doc/Zsh/compsys.yo	2002/01/21 16:03:56
@@ -270,6 +270,15 @@
 `var(cmd)tt(=)var(service)'.  This kind of use makes the arguments of
 the var(cmd)s be completed as those for the var(services).
 
+In the first case and the following cases the var(function) may actually
+be a string containing any shell code and that string will be executed
+via the tt(eval) builtin command.  This allows to easily define completions
+for commands that need to call one of the completion functions with
+arguments.  For example to make files ending in `tt(.h)' be completed as
+arguments to the command tt(foo), one would use:
+
+example(compdef '_files -g "*.h"' foo)
+
 If the
 tt(-n) option is given, any existing completion behaviour for particular
 contexts or commands will not be altered.  These definitions can be deleted
@@ -3518,13 +3527,17 @@
 the functions for the fields if they are called.
 )
 findex(_contexts)
-item(tt(_contexts) var(names) ...)(
+item(tt(_contexts) [ tt(-o) ] var(names) ...)(
 This function looks up the definitions for the context and command
 names given as arguments and calls the handler functions for them if
 there is a definition (given with the tt(compdef) function).  For
 example, the function completing inside subscripts might use
 `tt(_contexts -math-)' to include the completions generated for
 mathematical environments.
+
+If the tt(-o) option is given, tt(_contexts) returns after the first
+context for which completions could be generated, without trying the
+other contexts.
 )
 findex(_describe)
 item(tt(_describe) [ tt(-o) ] var(descr) var(name1) [ var(name2) ] var(opts) ... tt(-)tt(-) ...)(

-- 
Sven Wischnowsky                           wischnow@berkom.de