Re: PATCH: Re: _netscape

Re: PATCH: Re: _netscape

[Sven Wischnowsky]

I wrote:

> Oliver Kiddle wrote:
> 
> > ...
> > 
> > Basically, what a helper function needs to do is
> > take the suffix passed to it and when it is completing a final component
> > of itself, it should pass any suffix it wants with the one passed to it
> > appended. Pulling out -S options from "$@" is going to look messy
> > without some special handling at a lower level somewhere.
> 
> It's mostly a bit of [(i)...] stuff, but yes, it's probably common
> enough... One idea would be to add an option to zparseopts to allow it 
> to extract options. Actually, I've been wishing for something like
> that, too.

This is so simple to write that I think it's worth adding. So, this
adds the -E option to zparseopts that can be used to extract options
from the positional parameters. When combined with -D, the options
described are actually removed from $*.

Bye
 Sven

Index: Doc/Zsh/mod_zutil.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_zutil.yo,v
retrieving revision 1.6
diff -u -r1.6 mod_zutil.yo
--- Doc/Zsh/mod_zutil.yo	2000/05/22 09:32:33	1.6
+++ Doc/Zsh/mod_zutil.yo	2000/05/23 13:14:08
@@ -131,7 +131,7 @@
 This implements the internals of the `tt(_regex_arguments)'.
 )
 findex(zparseopts)
-item(tt(zparseopts) [ tt(-D) ] [ tt(-a) var(array) ] [ tt(-A) var(assoc) ] var(specs))(
+item(tt(zparseopts) [ tt(-D) ] [ tt(-E) ] [ tt(-a) var(array) ] [ tt(-A) var(assoc) ] var(specs))(
 This builtin simplifies the parsing of options in positional
 parameters, i.e. the set of arguments given by tt($*).  Each var(spec)
 describes one option and should be of the form
@@ -166,6 +166,9 @@
 positional parameters, up to but not including any not described by the
 var(specs).  This means that any options processed by tt(zparseopts) are
 removed from the positional parameters.
+
+The tt(-E) option allows to extract the options described by the
+var(specs) from the positional parameters, ignoring all other strings.
 
 For example,
 
Index: Src/Modules/zutil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zutil.c,v
retrieving revision 1.4
diff -u -r1.4 zutil.c
--- Src/Modules/zutil.c	2000/05/22 09:32:33	1.4
+++ Src/Modules/zutil.c	2000/05/23 13:14:09
@@ -1261,8 +1261,8 @@
 static int
 bin_zparseopts(char *nam, char **args, char *ops, int func)
 {
-    char *o, *p, *n, **pp, **aval, **ap, *assoc = NULL;
-    int del = 0, f;
+    char *o, *p, *n, **pp, **aval, **ap, *assoc = NULL, **cp, **np;
+    int del = 0, f, extract = 0;
     Zoptdesc sopts[256], d;
     Zoptarr a, defarr = NULL;
     Zoptval v;
@@ -1290,6 +1290,14 @@
 		}
 		del = 1;
 		break;
+	    case 'E':
+		if (o[2]) {
+		    args--;
+		    o = NULL;
+		    break;
+		}
+		extract = 1;
+		break;
 	    case 'a':
 		if (defarr) {
 		    zwarnnam(nam, "default array given more than once", NULL, 0);
@@ -1400,10 +1408,19 @@
 	if (!o[1])
 	    sopts[STOUC(*o)] = d;
     }
-    for (pp = pparams; (o = *pp); pp++) {
-	if (*o != '-')
-	    break;
+    np = cp = pp = ((extract && del) ? arrdup(pparams) : pparams);
+    for (; (o = *pp); pp++) {
+	if (*o != '-') {
+	    if (extract) {
+		if (del)
+		    *cp++ = o;
+		continue;
+	    } else
+		break;
+	}
 	if (!o[1] || (o[1] == '-' && !o[2])) {
+	    if (del && extract)
+		*cp++ = o;
 	    pp++;
 	    break;
 	}
@@ -1429,8 +1446,14 @@
 		} else
 		    add_opt_val(d, NULL);
 	    }
-	    if (!o)
-		break;
+	    if (!o) {
+		if (extract) {
+		    if (del)
+			*cp++ = *pp;
+		    continue;
+		} else
+		    break;
+	    }
 	} else {
 	    if (d->flags & ZOF_ARG) {
 		char *e = o + strlen(d->name) + 1;
@@ -1450,6 +1473,10 @@
 		add_opt_val(d, NULL);
 	}
     }
+    if (extract && del)
+	while (*pp)
+	    *cp++ = *pp++;
+
     for (a = opt_arrs; a; a = a->next) {
 	aval = (char **) zalloc((a->num + 1) * sizeof(char *));
 	for (ap = aval, v = a->vals; v; ap++, v = v->next) {
@@ -1498,9 +1525,15 @@
 	sethparam(assoc, aval);
     }
     if (del) {
-	pp = zarrdup(pp);
-	freearray(pparams);
-	pparams = pp;
+	if (extract) {
+	    *cp = NULL;
+	    freearray(pparams);
+	    pparams = zarrdup(np);
+	} else {
+	    pp = zarrdup(pp);
+	    freearray(pparams);
+	    pparams = pp;
+	}
     }
     return 0;
 }

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

Re: PATCH: Re: _netscape

[Oliver Kiddle]

Sven Wischnowsky wrote:

> > > Basically, what a helper function needs to do is
> > > take the suffix passed to it and when it is completing a final component
> > > of itself, it should pass any suffix it wants with the one passed to it
> > > appended. Pulling out -S options from "$@" is going to look messy
> > > without some special handling at a lower level somewhere.

> This is so simple to write that I think it's worth adding. So, this
> adds the -E option to zparseopts that can be used to extract options
> from the positional parameters. When combined with -D, the options
> described are actually removed from $*.

On the basis that compadd does only use the first -S option that it is
passed, being able to remove an option is not what is wanted: what is
wanted is a way to separate the first -S option and have it available in
a parameter.

If a helper function is completing only an initial portion of whatever
it completes, it is likely that what it needs to do is use its own
suffix, ignoring any passed to it - this we can do by inserting a new -S
option before the passed args. But, if a helper function is completing
the final portion of whatever it completes, it might want to use as a
suffix, the concatenation of its own suffix with the one which was
passed to it. For this, it would need to extract any suffix passed to it
as opposed to remove it. I'll also need to think about what will happen
with -r options aswell. This -E option well be very useful as it is but
it is not quite what I meant by 'pull out -S options from "$@"'.

Oliver

zparseopts change (Re: PATCH: Re: _netscape)

[Bart Schaefer]

On May 23,  3:15pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: _netscape
}
} +The tt(-E) option allows to extract the options described by the
} +var(specs) from the positional parameters, ignoring all other strings.

Could you make that just a little bit more verbose, please?  What does
"extract" mean?  How does "ignoring" affect the parsing?  E.g.,

	set -- -a x -b y -c -d z -- -e foo bar -f end
	zparseopts -a try1 b:
	zparseopts -a try2 a
	zparseopts -a try3 a: b: c
	zparseopts -a try4 a: b: c d: e:
	zparseopts -E -a try5 b: c d: e:
	zparseopts -E -a try6 a: b: c d: e: -
	echo try1 = $try1		# Parses nothing
	echo try2 = $try2		# Stops at x
	echo try3 = $try3		# Stops at -d
	echo try4 = $try4		# Stops at --
	echo try5 = $try5		# Does what?  Why?
	echo try6 = $try6		# Does what?  Why?

I could find out by trial-and-error, but should I have to?

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

Re: zparseopts change (Re: PATCH: Re: _netscape)

[Sven Wischnowsky]

Bart Schaefer wrote:

> On May 23,  3:15pm, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: Re: _netscape
> }
> } +The tt(-E) option allows to extract the options described by the
> } +var(specs) from the positional parameters, ignoring all other strings.
> 
> Could you make that just a little bit more verbose, please?  What does
> "extract" mean?  How does "ignoring" affect the parsing?  E.g.,

Hmhm. I can't do much better than this...

Bye
 Sven

Index: Doc/Zsh/mod_zutil.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_zutil.yo,v
retrieving revision 1.7
diff -u -r1.7 mod_zutil.yo
--- Doc/Zsh/mod_zutil.yo	2000/05/23 13:18:36	1.7
+++ Doc/Zsh/mod_zutil.yo	2000/05/23 14:58:04
@@ -156,6 +156,11 @@
 characters can appear in the option name provided it is preceded by a
 backslash.
 
+Unless the tt(-E) option is given, parsing stops at the first string
+that isn't described by one of the var(specs) And even with tt(-E),
+parsing always stops at a positional parameter equal to `tt(-)' or
+`tt(-)tt(-)'.
+
 If the tt(-A) option is given, the options and their values will also
 be put into an associative array with the option names as keys and the 
 arguments (if any) as the values.  Note that it is an error to give
@@ -167,8 +172,10 @@
 var(specs).  This means that any options processed by tt(zparseopts) are
 removed from the positional parameters.
 
-The tt(-E) option allows to extract the options described by the
-var(specs) from the positional parameters, ignoring all other strings.
+Since tt(-E) changes the parsing rules, it can be used to test for or
+(if used together with tt(-D)) extract options and their arguments,
+ignoring all other options and arguments that may be in the positional 
+parameters.
 
 For example,
 
@@ -181,5 +188,18 @@
 bar=(-b x -c y -c z))
 
 The arguments from `tt(baz)' on will not be used.
+
+As an example for the tt(-E) option, consider:
+
+example(set -- -a x -b y -c z arg1 arg2
+zparseopts -E -D b:=bar)
+
+will have the effect of
+
+example(bar=(-b y)
+set -- -a x -c z arg1 arg2)
+
+I.e., the option tt(-b) and its arguments are taken from the
+positional parameters and put into the array tt(bar).
 )
 enditem()

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