Re: PATCH: Re: Saving the zle display stuff

Re: PATCH: Re: Saving the zle display stuff

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Sven Wischnowsky wrote:
> > 
> > Oliver Kiddle wrote:
> 
> > > I seem to have some fairly long option exclusion lists in some of my
> > > completions so it might also be worth thinking if there are any better
> > > ways of doing the completion when there are separate forms of the
> > > command. I experimented with a few things like using two calls to
> > > _arguments without much success.
> > 
> > Yep. Any suggestions? ;-)
> 
> I've got some ideas but I'm not sure how workable they would be.
> 
> First, I suppose we would need some syntax to divide the arguments to
> _arguments into separate groups. At a simple level, you could say that
> each group defined the options for a separate form of the command and
> use something like '--' to separate the groups. The main additional
> functionality that this would offer over the current situation is that
> you could define separate non-option arguments (*:... or n:...) for each
> group.

`--' is alredy used for the automatic long-option stuff.

> ...
> 
> In summary, this is grouping the arguments and using common exclusion
> lists for the groups and allowing the groups to exclude other whole
> groups. You could easily expand the above to have longer exclusion lists
> and use the current syntax (although you couldn't deal with two -e and
> two * definitions).

The douled -e is indeed a problem. For one, _arguments currently can't 
report multiple actions (and is happy with the first one it finds if
it finds one). That can probably be changed (I'm not exactly sure how
complicated this would be). But of course, this would give us the same 
problem as for _alternative: the ->state actions. _arguments simply
cannot execute more than one of these because it doesn't execute them
at all. Maybe that could be changed to report all states that have to
be used to the caller, but then every function using multiple sets and 
->state has to be able to deal with that (rows of `if's instead of one
`case' or a `case' in a loop).

Hm. Maybe a wrapper (_multi_arguments) that turns these grouping stuff 
into normal _arguments descriptions (as you suggested) and then an
option to _arguments to allow it to deal with multiply given
options. And a way to say which of the multiple descriptions for the
same option is mutually exclusive, of course.

Bye
 Sven


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

Re: PATCH: Re: Saving the zle display stuff

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> Oliver Kiddle wrote:

> > I seem to have some fairly long option exclusion lists in some of my
> > completions so it might also be worth thinking if there are any better
> > ways of doing the completion when there are separate forms of the
> > command. I experimented with a few things like using two calls to
> > _arguments without much success.
> 
> Yep. Any suggestions? ;-)

I've got some ideas but I'm not sure how workable they would be.

First, I suppose we would need some syntax to divide the arguments to
_arguments into separate groups. At a simple level, you could say that
each group defined the options for a separate form of the command and
use something like '--' to separate the groups. The main additional
functionality that this would offer over the current situation is that
you could define separate non-option arguments (*:... or n:...) for each
group.

Many commands will have some options which are common to their different
forms though so a syntax which allows groups to be labelled and excluded
as a whole would avoid any repetition in the arguments. So for example,
you might have:

_arguments -C \
  '(form2 form3)form1:' \
    '-e:files:_files' \
  '(form1 form3)form2:' \
    '(-f)-a: ...
    '-e:...:_users' \
    '(-a -r)-f: ...
  '(common form1 form2)form3:' \
    '-l: ...
    '*:users:_users' \
  '(form3)common:' \
    '(-f)-r: ...
    '*:files:_files'

Here, I have used the labels form1, form2, form3 and common. Hopefully
the syntax is clear; there may be better ways of representing it. Here
the command would have 3 forms. The first two have separate parameters
which are defined in their respective groups (form1 has the -e option
and form2 has a -a, -f and a different -e option). They both share the
arguments defined in the common group (a -r option and files being
completed ordinarily). The third form of the command just has a -l
option - it doesn't use anything from the common group. In addition it
completes users ordinarily. The -e option raises one issue because there
are two different definitions - in form1 and form2. Initially, both
users and files would be completed after -e but if at any point a -a or
-f option was used, only users (form2) would be completed. There would
be a similar situation initially for the '*:... arguments. Anything
which excluded (*) would exclude both (would there be a problem with
this?).

In summary, this is grouping the arguments and using common exclusion
lists for the groups and allowing the groups to exclude other whole
groups. You could easily expand the above to have longer exclusion lists
and use the current syntax (although you couldn't deal with two -e and
two * definitions).

Does this make sense? Is this suggestion far too complicated?

Finally, thanks Sven for that solution for command-completion taking
ages problem. That works very nicely thanks.

Oliver Kiddle

PATCH: Re: Saving the zle display stuff

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> An alternative which might be worth thinking about is to allow all lines
> in _arguments to specify a list of options with which they are mutually
> exclusive. So in the vase of _zpty, I would use:
>   '(-r)*::args:_normal'
> as the last line.

Ah, right. That's nice. And not too hard to implement either, see
below.

Maybe we should change or enhance that to allow numbers (disallowing
individual normal arguments) and `*' (disallowing rest-arguments)
after a certain option. The patch tries to implement that, too.

> ...
> 
> I seem to have some fairly long option exclusion lists in some of my
> completions so it might also be worth thinking if there are any better
> ways of doing the completion when there are separate forms of the
> command. I experimented with a few things like using two calls to
> _arguments without much success.

Yep. Any suggestions? ;-)

Bye
 Sven

diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Tue Mar 14 11:41:20 2000
+++ Doc/Zsh/compsys.yo	Tue Mar 14 15:58:54 2000
@@ -2339,15 +2339,6 @@
 If the option may be given more than once, a star
 (`tt(*)') has to be added in front of the var(opt-spec).
 
-An var(opt-spec) may also contain a list of other option names with
-which the option described is mutually exclusive. Such a list is given 
-in parentheses at the beginning, as in `tt((-two -three)-one:...)'. In 
-this example, the options `tt(-two)' and `tt(-three)' will not be
-offered as possible completions if the option `tt(-one)' is on the
-line. Also, the list may contain a single colon as one of its elements 
-to specify that the descriptions for normal (non-option-) arguments
-should not be used if the option described is on the line.
-
 Finally, the var(opt-spec) may contain a explanation string. This is
 given in brackets at the end, as in `tt(-q[query operation])'. The
 tt(verbose) style is used to decide if these
@@ -2359,6 +2350,18 @@
 first argument.
 )
 enditem()
+
+Every var(spec) may also contain a list of option names and argument
+numbers with which the option or argument described is mutually
+exclusive. Such a list is given in parentheses at the beginning, as in
+`tt((-two -three 1)-one:...)' or `tt((-foo):...)'. In the first
+example, the options `tt(-two)' and `tt(-three)' and the first
+argument will not be offered as possible completions if the option
+`tt(-one)' is on the line. Also, the list may contain a single star as
+one of its elements to specify that the description for the rest
+arguments should not be used and it may contain a colon to specify
+that the descriptions for all normal (non-option-) arguments should
+not be used.
 
 In each of the cases above, the var(action) says how the possible
 completions should be generated. In cases where only one of a fixed
diff -ru ../z.old/Src/Zle/computil.c Src/Zle/computil.c
--- ../z.old/Src/Zle/computil.c	Tue Mar 14 11:41:14 2000
+++ Src/Zle/computil.c	Tue Mar 14 15:51:20 2000
@@ -329,11 +329,13 @@
 struct caarg {
     Caarg next;
     char *descr;		/* description */
+    char **xor;			/* if this, then not ... */
     char *action;		/* what to do for it */
     int type;			/* CAA_* below */
     char *end;			/* end-pattern for ::<pat>:... */
     char *opt;			/* option name if for an option */
     int num;			/* it's the num'th argument */
+    int active;			/* still allowed on command line */
 };
 
 #define CAA_NORMAL 1
@@ -375,6 +377,8 @@
     for (; a; a = n) {
 	n = a->next;
 	zsfree(a->descr);
+	if (a->xor)
+	    freearray(a->xor);
 	zsfree(a->action);
 	zsfree(a->end);
 	zsfree(a->opt);
@@ -457,6 +461,7 @@
 
     ret->next = NULL;
     ret->descr = ret->action = ret->end = NULL;
+    ret->xor = NULL;
     ret->num = num;
     ret->type = type;
     ret->opt = ztrdup(oname);
@@ -806,6 +811,7 @@
 		    type = CAA_RARGS;
 	    }
 	    ret->rest = parse_caarg(0, type, -1, NULL, &p);
+	    ret->rest->xor = xor;
 	} else {
 	    /* It's a normal argument definition. */
 
@@ -835,6 +841,7 @@
 		p++;
 	    }
 	    arg = parse_caarg(0, type, anum - 1, NULL, &p);
+	    arg->xor = xor;
 
 	    /* Sort the new definition into the existing list. */
 
@@ -970,10 +977,10 @@
 	while (a && a->num < n)
 	    a = a->next;
 
-	if (a && a->num == n)
+	if (a && a->num == n && a->active)
 	    return a;
 
-	return d->rest;
+	return (d->rest && d->rest->active ? d->rest : NULL);
     }
     return NULL;
 }
@@ -989,7 +996,19 @@
 	for (; *xor; xor++) {
 	    if (xor[0][0] == ':' && !xor[0][1])
 		d->argsactive = 0;
-	    else if ((opt = ca_get_opt(d, *xor, 1, NULL)))
+	    else if (xor[0][0] == '*' && !xor[0][1]) {
+		if (d->rest)
+		    d->rest->active = 0;
+	    } else if (xor[0][0] >= '0' && xor[0][0] <= '9') {
+		int n = atoi(xor[0]);
+		Caarg a = d->args;
+
+		while (a && a->num < n)
+		    a = a->next;
+
+		if (a && a->num == n)
+		    a->active = 0;
+	    } else if ((opt = ca_get_opt(d, *xor, 1, NULL)))
 		opt->active = 0;
 	}
     }
@@ -1019,7 +1038,7 @@
     Caarg adef, ddef;
     Caopt ptr, wasopt;
     struct castate state;
-    char *line, *pe;
+    char *line, *pe, **argxor = NULL;
     int cur, doff;
     Patprog endpat = NULL;
 
@@ -1041,6 +1060,10 @@
     for (ptr = d->opts; ptr; ptr = ptr->next)
 	ptr->active = 1;
     d->argsactive = 1;
+    if (d->rest)
+	d->rest->active = 1;
+    for (adef = d->args; adef; adef = adef->next)
+	adef->active = 1;
 
     /* Default values for the state. */
 
@@ -1072,6 +1095,8 @@
 	ddef = adef = NULL;
 	doff = state.singles = 0;
 
+	ca_inactive(d, argxor);
+
 	/* We've a definition for an argument, skip to the next. */
 
 	if (state.def) {
@@ -1201,6 +1226,9 @@
 		break;
 	    }
 	    zaddlinknode(state.args, ztrdup(line));
+
+	    if (state.def)
+		argxor = state.def->xor;
 
 	    if (state.def && state.def->type != CAA_NORMAL &&
 		state.def->type != CAA_OPT && state.inarg) {

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