-subscript- completion for assoc array

-subscript- completion for assoc array

[Peter Stephenson]

Is there some math mode behaviour still built into subscript completion?  I
can't complete the -*- elements of _comps, although they are listed all
right immediately after the [ and are entered OK with menu completion.

% $_comps[-def<TAB>

tries to complete variable names.  Significantly, it claims it's allowing
two errors and the set I get is

fignore      hep_env_sh   perl5lib     testhash     vers         
foo          keys         ret          texinputs    
fpath        lf           sets         ufmt         

so I suspect the - has been chucked out at some point.  (Since you're
wondering :-), the list consists of variables starting in f (delete two
characters) or with e second (replace two characters) or with f second
(delete one and transpose the other two).)

I don't think it matters much, but I'm now using the slightly modified
_subscript below.  (It does show I shouldn't get the variable names at all
in this case and hence compstate[parameter] isn't set properly, either.)


#defcomp -subscript-

if [[ ${(Pt)${compstate[parameter]}} = assoc* ]]; then
  compgen -k "( ${(kP)${compstate[parameter]}} )"
else
  _compalso -math-
fi


-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: -subscript- completion for assoc array

[Sven Wischnowsky]

Peter Stephenson wrote:

> Is there some math mode behaviour still built into subscript completion?  I
> can't complete the -*- elements of _comps, although they are listed all
> right immediately after the [ and are entered OK with menu completion.
> 
> % $_comps[-def<TAB>
> 
> tries to complete variable names.  Significantly, it claims it's allowing
> two errors and the set I get is
> 
> fignore      hep_env_sh   perl5lib     testhash     vers         
> foo          keys         ret          texinputs    
> fpath        lf           sets         ufmt         
> 
> so I suspect the - has been chucked out at some point.  (Since you're
> wondering :-), the list consists of variables starting in f (delete two
> characters) or with e second (replace two characters) or with f second
> (delete one and transpose the other two).)

The patch below only makes the parameter name correctly handled.

The problem with the missing `-' is not handled, but I found the
reason for it (and am not sure how we should change it). The reason is 
that inside subscripts, match-mode parsing is done to get the string
to complete, which normally is a string of characters on which
`iident(c)' yields true. This is what one wants in math envs including 
normal subscripts. Hm, I have to leave now so I won't be able to send
a patch for this now (hance this mail). I'll think some more about
this, but if some of you have ideas, let me know.
Possibilities include: give the whole subscript string to the function 
(which is a bit ugly for normal subscripts), and let the C-code find
out what kind of parameter we have -- and let it report a new context
for assocs.

> I don't think it matters much, but I'm now using the slightly modified
> _subscript below.  (It does show I shouldn't get the variable names at all
> in this case and hence compstate[parameter] isn't set properly, either.)

I think this is reasonable (and it seems I didn't think when writing
that...), so the patch below also changes `_subscript'


Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Mar 15 10:52:39 1999
+++ Src/Zle/zle_tricky.c	Mon Mar 15 16:43:38 1999
@@ -1322,18 +1322,17 @@
 	 * as being in math.                                              */
 	if (inwhat != IN_MATH) {
 	    int i = 0;
-	    char *nb = (iident(*s) ? s : s + 1), *ne = NULL;
+	    char *nnb = (iident(*s) ? s : s + 1), *nb = NULL, *ne = NULL;
 
 	    for (tt = s; ++tt < s + cs - wb;)
 		if (*tt == Inbrack) {
 		    i++;
+		    nb = nnb;
 		    ne = tt;
 		} else if (i && *tt == Outbrack)
 		    i--;
-		else if (!iident(*tt)) {
-		    nb = tt + 1;
-		    ne = NULL;
-		}
+		else if (!iident(*tt))
+		    nnb = tt + 1;
 	    if (i) {
 		inwhat = IN_MATH;
 		insubscr = 1;
diff -u oc/Base/_subscript Completion/Base/_subscript
--- oc/Base/_subscript	Mon Mar 15 10:08:48 1999
+++ Completion/Base/_subscript	Mon Mar 15 16:51:33 1999
@@ -1,10 +1,7 @@
 #defcomp -subscript-
 
-local ret=1
-
-_compalso -math- && ret=0
-
-[[ ${(Pt)${compstate[parameter]}} = assoc* ]] &&
-  compgen -k "( ${(kP)${compstate[parameter]}} )" && ret=0
-
-return ret
+if [[ ${(Pt)${compstate[parameter]}} = assoc* ]]; then
+  compgen -S ']' -k "( ${(kP)${compstate[parameter]}} )"
+else
+  _compalso -math-
+fi

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

Re: -subscript- completion for assoc array

[Peter Stephenson]

Sven Wischnowsky wrote:
> The problem with the missing `-' is not handled, but I found the
> reason for it (and am not sure how we should change it). The reason is 
> that inside subscripts, match-mode parsing is done to get the string
> to complete, which normally is a string of characters on which
> `iident(c)' yields true. This is what one wants in math envs including 
> normal subscripts. Hm, I have to leave now so I won't be able to send
> a patch for this now (hance this mail). I'll think some more about
> this, but if some of you have ideas, let me know.
> Possibilities include: give the whole subscript string to the function 
> (which is a bit ugly for normal subscripts), and let the C-code find
> out what kind of parameter we have -- and let it report a new context
> for assocs.

I wouldn't have thought it would be too hard just to pass the whole string
to the -subscript- handler, and inside that, if the parameter is not an
assoc, simply IPREFIXify anything which is not alphanumeric before handing
the rest on to the -math- handler.  You don't even need special handling
for variables with funny names, since they're always a single character so
can't be completed further.  Unless I've missed something.

You could even argue that the -math- handler could be made responsible for
deciding what to complete and what to IPREFIXify in every case.  After
thinking about it, I like this better, since it keeps string handling
consistent within math-like contexts.  It also allows you to have
completion for the whole expression.  For example, you could arrange for

(( <TAB>                  # -> selection of parameters as usual
(( foo <TAB>              # -> matches "[a-z]  *", cycle through selection
                          #    of operators
(( foo + <TAB>            # -> it's a +, generate my own special
                          #    list of numbers to add to: 3.14159, 42,
                          #    1000009, ...

I'm not suggesting it's actually worth writing a function which does any of
that apart from the first bit, even I can type `++' without feeling the
need to hit TAB, but simply that it increases flexibility and decreases
special-casing in the C code if this is transferred to the shell function.

(Except, of course, when calling old completion, in which case you've got
to do as much as is reasonable in C.)


By the way, it's a bit annoying that the command is called `compdef' while
the lines at the tops of the functions to do the same thing automatically
are still `defcomp' etc.  If it's not yet too late, it might be a good idea
to change these to `compdef', `compdefpat' and `compdefkey'.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: -subscript- completion for assoc array

[Sven Wischnowsky]

Peter Stephenson wrote:

> I wouldn't have thought it would be too hard just to pass the whole string
> to the -subscript- handler, and inside that, if the parameter is not an
> assoc, simply IPREFIXify anything which is not alphanumeric before handing
> the rest on to the -math- handler.  You don't even need special handling
> for variables with funny names, since they're always a single character so
> can't be completed further.  Unless I've missed something.

Ok, the patch below makes completion functions get the whole string -- 
almost. This has a small problem with things like `(( 8*((x-1+f<TAB>'.
Here it stops at the `((' before the `x', thinking it is the beginning 
of a `((...' or a `$((...'.

And this finally could me implement a `ISUFFIX' parameter, so that we
could make this correctly if there is something after the cursor. I've 
been wishing for this when implementing `_tilde' already. Maybe I
build this into the tricky.c-cleanup I'm currently busy with.

> (Except, of course, when calling old completion, in which case you've got
> to do as much as is reasonable in C.)

This will behave the same way it ever did, i.e. I haven't built in
some magic to complete the keys of assoc arrays.

> By the way, it's a bit annoying that the command is called `compdef' while
> the lines at the tops of the functions to do the same thing automatically
> are still `defcomp' etc.  If it's not yet too late, it might be a good idea
> to change these to `compdef', `compdefpat' and `compdefkey'.

Yes, I've been thinking about this, too. Although I probably would
prefer `#compdef -p ...' and `#compdef -k ...'.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Mar 15 16:57:14 1999
+++ Src/Zle/zle_tricky.c	Tue Mar 16 11:38:47 1999
@@ -1346,12 +1346,35 @@
 	    }
 	}
 	if (inwhat == IN_MATH) {
-	    /* In mathematical expression, we complete parameter names (even *
-	     * if they don't have a `$' in front of them).  So we have to    *
-	     * find that name.                                               */
-	    for (we = cs; iident(line[we]); we++);
-	    for (wb = cs; --wb >= 0 && iident(line[wb]););
-	    wb++;
+	    if (compfunc) {
+		int lev;
+		char *p;
+
+		for (wb = cs - 1, lev = 0; wb > 0; wb--)
+		    if (line[wb] == ']' || line[wb] == ')')
+			lev++;
+		    else if (line[wb] == '[') {
+			if (!lev--)
+			    break;
+		    } else if (line[wb] == '(') {
+			if (!lev && line[wb - 1] == '(')
+			    break;
+			if (lev)
+			    lev--;
+		    }
+		wb++;
+		p = (char *) line + wb;
+		if (wb && (*p == '[' || *p == '(') &&
+		    !skipparens(*p, (*p == '[' ? ']' : ')'), &p))
+			we = p - (char *) line;
+	    } else {
+		/* In mathematical expression, we complete parameter names  *
+		 * (even if they don't have a `$' in front of them).  So we *
+		 * have to find that name.                                  */
+		for (we = cs; iident(line[we]); we++);
+		for (wb = cs; --wb >= 0 && iident(line[wb]););
+		wb++;
+	    }
 	    zsfree(s);
 	    s = zalloc(we - wb + 1);
 	    strncpy(s, (char *) line + wb, we - wb);
@@ -5240,14 +5263,20 @@
 	zsfree(compprefix);
 	zsfree(compsuffix);
 	if (unset(COMPLETEINWORD)) {
-	    tmp = quotename(s, NULL, NULL, NULL);
+	    if (inwhat == IN_MATH)
+		tmp = s;
+	    else
+		tmp = quotename(s, NULL, NULL, NULL);
 	    untokenize(tmp);
 	    compprefix = ztrdup(tmp);
 	    compsuffix = ztrdup("");
 	} else {
 	    char *ss = s + offs, sav;
 	    
-	    tmp = quotename(s, &ss, NULL, NULL);
+	    if (inwhat == IN_MATH)
+		tmp = s;
+	    else
+		tmp = quotename(s, &ss, NULL, NULL);
 	    sav = *ss;
 	    *ss = '\0';
 	    untokenize(tmp);
diff -u oc/Base/_math Completion/Base/_math
--- oc/Base/_math	Tue Mar 16 10:29:34 1999
+++ Completion/Base/_math	Tue Mar 16 11:43:35 1999
@@ -0,0 +1,6 @@
+#defcomp -math-
+
+IPREFIX="$IPREFIX${PREFIX%[a-zA-Z0-9_]*}"
+PREFIX="${PREFIX##*[^a-zA-Z0-9_]}"
+
+compgen -v
diff -u oc/Base/_vars Completion/Base/_vars
--- oc/Base/_vars	Mon Mar 15 16:57:24 1999
+++ Completion/Base/_vars	Tue Mar 16 10:29:20 1999
@@ -1,3 +1,3 @@
-#defcomp -math- getopts read unset vared
+#defcomp getopts read unset vared
 
 compgen -v

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