Re: PATCH: completion

Re: PATCH: completion

[Sven Wischnowsky]

Tanaka Akira wrote:

> GNU getopt_long supports the style.
> 
> getopt_long(3):
> 
>        The getopt_long() function works like getopt() except that
>        it  also  accepts long options, started out by two dashes.
>        Long option names may be abbreviated if  the  abbreviation
>        is unique or is an exact match for some defined option.  A
>        long option may take a parameter, of the form  --arg=param
>        or --arg param.
> 
> So, many GNU commands accept that.

Urgh. Sorry, didn't know about that. Hrmpf, do we have to make
`_long_options' accept these? Should we join `_arguments' and
`_long_options'? Hm.

> This is because "-a" in compadd arguments. It is the result of
> expansion of "dopts[${(@)^dopts[(I)${ws[1][1]}[$uns]]}]" and
> "odopts[${(@)^odopts[(I)${ws[1][1]}[$uns]]}]".

Ah, sorry, I didn't test it with `[(I)...]'. So I think this is a real 
bug, to be fixed in C. I'd like to hear Bart about this, though,
because there was explicit code to turn empty array-subscripts into
non-arrays. Maybe the effect this had on associations subscripted with 
`[(I)...]' and `[(R)...]' was pure oversight, though.

Bye
 Sven

diff -u os/params.c Src/params.c
--- os/params.c	Fri Aug 20 15:18:08 1999
+++ Src/params.c	Mon Aug 23 13:56:27 1999
@@ -940,7 +940,9 @@
 			v->isarr |= SCANPM_MATCHVAL;
 		    if (down)
 			v->isarr |= SCANPM_MATCHMANY;
-		    if ((ta = getvaluearr(v)) && *ta) {
+		    if ((ta = getvaluearr(v)) &&
+			(*ta || ((v->isarr & SCANPM_MATCHMANY) &&
+				 (v->isarr & (SCANPM_MATCHKEY | SCANPM_MATCHVAL))))) {
 			*inv = v->inv;
 			*w = v->b;
 			return 1;
@@ -1117,7 +1119,9 @@
 	    }
 	    if (*s == ']' || *s == Outbrack) {
 		s++;
-		if (v->isarr && a == b)
+		if (v->isarr && a == b && 
+		    (!(v->isarr & SCANPM_MATCHMANY) ||
+		     !(v->isarr & (SCANPM_MATCHKEY | SCANPM_MATCHVAL))))
 		    v->isarr = 0;
 		v->a = a;
 		v->b = b;

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

Empty [(I)...] subscripting of assoc arrays (was Re: PATCH: completion)

[Bart Schaefer]

I think we now have entirely too many topics going on that all have the
subject "Re: PATCH: completion".

On Aug 23,  2:00pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: completion
}
} > This is because "-a" in compadd arguments. It is the result of
} > expansion of "dopts[${(@)^dopts[(I)${ws[1][1]}[$uns]]}]" and
} > "odopts[${(@)^odopts[(I)${ws[1][1]}[$uns]]}]".
} 
} Ah, sorry, I didn't test it with `[(I)...]'. So I think this is a real 
} bug, to be fixed in C. I'd like to hear Bart about this, though,
} because there was explicit code to turn empty array-subscripts into
} non-arrays. Maybe the effect this had on associations subscripted with 
} `[(I)...]' and `[(R)...]' was pure oversight, though.

It was oversight in that I didn't consider it; but either the patch you
sent is correct or else it's going to cause a core dump at subst.c:1713 

	    i = 1;
	    /* aval[1] is non-null here */
	    while (aval[i + 1]) {

in some circumstances that I'm not able to predict offhand.  I tend to
think it'll be OK.

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