completion in vared

completion in vared

[Peter Stephenson]

(Guess who this is mainly directed to?)

Any thoughts about completion in vared?  Would it be possible to get it to
start completion with the context set to _value or _array_value, and
compstate[parameter] set?  (Maybe even a special compstate flag, but I'm
not particular about that and don't necessarily have a use for it.)

-- 
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: completion in vared

[Bart Schaefer]

On Apr 28,  5:00pm, Peter Stephenson wrote:
} Subject: completion in vared
} 
} Any thoughts about completion in vared?  Would it be possible to get it to
} start completion with the context set to _value or _array_value, and
} compstate[parameter] set?

How about something like

	function vared {
	    local _complete_vared=${(Pt)1}
	    builtin vared "$@"
	}

And then somewhere (I'm not familiar enough with it yet to be sure where)
in the completion functions, do

	case $_complete_vared in
	array|association) compstate[parameter]=$words[1]
			   compstate[context]=_array_value;;
	scalar) compstate[parameter]=$words[1]
		compstate[context]=_value;;
	*) ;;
	esac

Obviously some tweaking is needed to handle "vared -c ..." and so on, but
you get the idea.

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

Re: completion in vared

[Sven Wischnowsky]

Bart Schaefer wrote:

> No, I'm mostly thinking of the compctl options that have poor mnemonics,
> and particularly of -J and -V (which are begging for a bracketed-looking
> syntax).

Are you meaning something like: start-group, ..., end-group?

In the beginning we had -[JV] set the group permanently (until the
next -[JV]) which was nearer to this but then I decided against it
because in more complex compctl's (or now: completion functions) you
would always have to use it to make sure that you know which group you 
are using. And with such a pair you would have to remember to reset
it. Also, to make this usable we would have to implement a kind of
stack, so that the end-group resets it to the previous group again.

> There is some advantage to having the options of the new commands be the
> same as those of compctl, but I'm not sure if it's enough to outweigh the
> opportunity to clean it up a bit.

Right, we might think about this. For me, the most important advantage 
of the current implementation is that it can easily share all the
parsing code with compctl. I might be convinced to change it, though.

Bye
 Sven


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

Re: completion in vared

[Bart Schaefer]

On Apr 30,  9:07am, Sven Wischnowsky wrote:
} Subject: Re: completion in vared
}
} 
} Bart Schaefer wrote:
} > By the way, if we're reasonably confident that we've now identified all
} > the compctl-isms that it's useful to put into compadd/gen/etc., I think
} > we should seriously look at rewriting the option parsing for those new
} > commands to abandon the compctl syntax.
} 
} I /think/ you are referring to an old suggestion to just give a
} builtin that gets the matches to be added directly (that would be
} compadd) and let the user generate these matches/words through shell
} code.

No, I'm mostly thinking of the compctl options that have poor mnemonics,
and particularly of -J and -V (which are begging for a bracketed-looking
syntax).

There is some advantage to having the options of the new commands be the
same as those of compctl, but I'm not sure if it's enough to outweigh the
opportunity to clean it up a bit.

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

Re: completion in vared

[Sven Wischnowsky]

Bart Schaefer wrote:

> If there are more than 32 special completion parameters, I think we've
> failed in our goal to make the whole system easier to understand.

I'm not so sure about that. There are eight parameters, all the rest
is in compstate, not always set, etc. Sure, some of the keys in
compstate are powerful enough to be called complicated, but most of
them are quite simple, I think.

> By the way, if we're reasonably confident that we've now identified all
> the compctl-isms that it's useful to put into compadd/gen/etc., I think
> we should seriously look at rewriting the option parsing for those new
> commands to abandon the compctl syntax.  Part of the reason for creating
> the new system was because compctl was so hard to comprehend; we've made
> the new system a lot more powerful, but made little progress on making
> it easy to understand.  So far we've mostly taken the confusing compctl
> stuff, stick new command names in front of it, and wrap it in confusing
> shell-script stuff.

I'm always open to suggestions (I hope I made that clear enough from
the beginning). But I always thought the problem with compctl was the
`-x'-stuff, the `+' stuff, and things like that. This *is* removed in
the new completion system (you can't even use `+' or `-x' with
compgen), this reduces compgen to just the simple flags of compctl.

I /think/ you are referring to an old suggestion to just give a
builtin that gets the matches to be added directly (that would be
compadd) and let the user generate these matches/words through shell
code. The problem is that some of the things compgen can easily
generate currently can not be simply generated by the user (or: not as 
fast and simple). This may change if we have access to more shell
interna through special associative arrays or whatever. But still:
would this be easier to use or understand?

Again, I'd be willing to change many things if anyone gives me a good
reason to do this. I wished we had more users testing all this stuff...

> Yes, I'm exaggerating a little, but you can't really say the flow of
> control is obvious through the current set of completion functions.

Hm. Users don't have to worry about this in almost all cases. At least 
if they are writing completion functions for commands/contexts, and not 
even when writing completers, I think (which would probably count as
being something for advanced users).

Bye
 Sven


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

Re: completion in vared

[Bart Schaefer]

On Apr 29, 11:05am, Sven Wischnowsky wrote:
} Subject: Re: completion in vared
}
} Sidenote: The code uses a mask to say which of the special completion
}           parameters should be set or unset. With compstate[vared] we
}           have reached 32. If anyone comes up with an idea for another 
}           key, I'll have to re-write a bit more of the code (seven
}           bits can be freed, after that I would have to change even
}           more).

If there are more than 32 special completion parameters, I think we've
failed in our goal to make the whole system easier to understand.

By the way, if we're reasonably confident that we've now identified all
the compctl-isms that it's useful to put into compadd/gen/etc., I think
we should seriously look at rewriting the option parsing for those new
commands to abandon the compctl syntax.  Part of the reason for creating
the new system was because compctl was so hard to comprehend; we've made
the new system a lot more powerful, but made little progress on making
it easy to understand.  So far we've mostly taken the confusing compctl
stuff, stick new command names in front of it, and wrap it in confusing
shell-script stuff.

Yes, I'm exaggerating a little, but you can't really say the flow of
control is obvious through the current set of completion functions.

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

Re: completion in vared

[Sven Wischnowsky]

Peter Stephenson wrote:

> Any thoughts about completion in vared?  Would it be possible to get it to
> start completion with the context set to _value or _array_value, and
> compstate[parameter] set?  (Maybe even a special compstate flag, but I'm
> not particular about that and don't necessarily have a use for it.)

I had thought about this some time ago, then forgot it again. And I 
was mostly thinking about something like what Bart suggested, but...

Well, I wouldn't like it to unconditionally set compstate[context] to
(array_|)value because sometimes one might want to let the user edit a 
command line which is then `eval'ed or something like that. Then
normal command completion would be nice, of course.

*But* we probably should allow the completion widget writer to find
out that vared is active. So the patch below adds compstate[vared]
which is set to the argument that is currently varedited. With that
one could do (e.g. in the function for the -first- context):

    if [[ -n $compstate[vared] ]]; then
      if [[ $compstate[vared] = *\[* ]]; then
        compstate[parameter]=${compstate[vared]%%\[*}
        compstate[context]=value
      else
        compstate[parameter]=$compstate[vared]
        if [[ ${(tP)compstate[vared]} = *(array|assoc)* ]]; then
          compstate[context]=array_value
        else
          compstate[context]=value
        fi
      fi
      return
    fi

to set up compstate accordingly. (This is another example of how a
example _first function might be useful. Does anyone have one? Any
other suggestions about what we might put there? (If I were to add it, 
I would put everything in it in comments, not disturbing completion
but explaining what can be done.))

Are there other places where completion might get called from (other
than normal line editing and vared)? If so, we should change the
key/value to be able to reflect these other circumstances.

But in reply to Bart: I, too, had thought about a special variable
which is tested by the completion (shell-)code, and, if it is set,
it's value is used as the name of the context to use. So I would put
it into _complete and it would allow us to use the normal context-
distribution and -definition mechanism. Hm, does this sound ok? Any
suggestions for the name?

Bye
 Sven

Sidenote: The code uses a mask to say which of the special completion
          parameters should be set or unset. With compstate[vared] we
	  have reached 32. If anyone comes up with an idea for another 
	  key, I'll have to re-write a bit more of the code (seven
	  bits can be freed, after that I would have to change even
	  more).

P.S.: The patch also contains two small fixes where I forgot to
      include the mask for ISUFFIX. IF a function usetted that it
      wasn't restored after function exit again (well, the value was
      restored all right, but it didn't re-appear).


diff -u os/Zle/comp.h Src/Zle/comp.h
--- os/Zle/comp.h	Thu Apr 29 10:14:47 1999
+++ Src/Zle/comp.h	Thu Apr 29 10:24:33 1999
@@ -331,7 +331,8 @@
 #define CP_TOEND      (1 << 28)
 #define CP_OLDLIST    (1 << 29)
 #define CP_OLDINS     (1 << 30)
+#define CP_VARED      (1 << 31)
 
-#define CP_NUM              31
+#define CP_NUM              32
 
-#define CP_ALLMASK    ((int) ((((unsigned int) 1) << CP_NUM) - 1))
+#define CP_ALLMASK    ((unsigned int) 0xffffffff)
diff -u os/Zle/comp1.c Src/Zle/comp1.c
--- os/Zle/comp1.c	Thu Apr 29 10:14:47 1999
+++ Src/Zle/comp1.c	Thu Apr 29 10:26:28 1999
@@ -129,7 +129,8 @@
      *complastprompt,
      *comptoend,
      *compoldlist,
-     *compoldins;
+     *compoldins,
+     *compvared;
 
 /**/
 Param *comppms;
@@ -445,7 +446,7 @@
 	compquoting = comprestore = complist = compinsert =
 	compexact = compexactstr = comppatmatch = comppatinsert =
 	compforcelist = complastprompt = comptoend = 
-	compoldlist = compoldins = NULL;
+	compoldlist = compoldins = compvared = NULL;
     makecompparamsptr = NULL;
     comp_setunsetptr = NULL;
     return 0;
@@ -497,6 +498,7 @@
     zsfree(comptoend);
     zsfree(compoldlist);
     zsfree(compoldins);
+    zsfree(compvared);
     return 0;
 }
 
diff -u os/Zle/compctl.c Src/Zle/compctl.c
--- os/Zle/compctl.c	Thu Apr 29 10:14:47 1999
+++ Src/Zle/compctl.c	Thu Apr 29 10:38:32 1999
@@ -2173,6 +2173,7 @@
     { "to_end", PM_SCALAR, VAL(comptoend), NULL, NULL },
     { "old_list", PM_SCALAR, VAL(compoldlist), NULL, NULL },
     { "old_insert", PM_SCALAR, VAL(compoldins), NULL, NULL },
+    { "vared", PM_SCALAR, VAL(compvared), NULL, NULL },
     { NULL, 0, NULL, NULL, NULL }
 };
 
@@ -2316,7 +2317,7 @@
 
 /**/
 void
-comp_setunset(int set, int unset)
+comp_setunset(unsigned int set, unsigned int unset)
 {
     Param *p;
 
@@ -2342,11 +2343,11 @@
     else {
 	char *orest, *opre, *osuf, *oipre, *oisuf, **owords;
 	long ocur;
-	int unset = 0, m, sm;
+	unsigned int unset = 0, m, sm;
 	Param *pp;
 
 	m = CP_WORDS | CP_CURRENT | CP_PREFIX | CP_SUFFIX | 
-	    CP_IPREFIX | CP_RESTORE;
+	    CP_IPREFIX | CP_ISUFFIX | CP_RESTORE;
 	for (pp = comppms, sm = 1; m; pp++, m >>= 1, sm <<= 1) {
 	    if ((m & 1) && ((*pp)->flags & PM_UNSET))
 		unset |= sm;
@@ -2381,7 +2382,8 @@
 	    } LASTALLOC;
 	    comp_setunset(CP_COMPSTATE |
 			  (~unset & (CP_WORDS | CP_CURRENT | CP_PREFIX |
-				     CP_SUFFIX | CP_IPREFIX | CP_RESTORE)),
+				     CP_SUFFIX | CP_IPREFIX | CP_ISUFFIX |
+				     CP_RESTORE)),
 			  unset);
 	} else
 	    comp_setunset(CP_COMPSTATE | (~unset & CP_RESTORE),
diff -u os/Zle/zle_main.c Src/Zle/zle_main.c
--- os/Zle/zle_main.c	Thu Apr 29 10:14:47 1999
+++ Src/Zle/zle_main.c	Thu Apr 29 10:36:33 1999
@@ -656,14 +656,18 @@
 	initmodifier(&zmod);
 }
 
+/* this exports the argument we are currently vared'iting if != NULL */
+
+/**/
+char *varedarg;
+
 /* vared: edit (literally) a parameter value */
 
 /**/
 static int
 bin_vared(char *name, char **args, char *ops, int func)
 {
-    char *s;
-    char *t;
+    char *s, *t, *ova = varedarg;
     Value v;
     Param pm = 0;
     int create = 0;
@@ -753,7 +757,9 @@
     PERMALLOC {
 	pushnode(bufstack, ztrdup(s));
     } LASTALLOC;
+    varedarg = *args;
     t = (char *) zleread(p1, p2, ops['h'] ? ZLRF_HISTORY : 0);
+    varedarg = ova;
     if (!t || errflag) {
 	/* error in editing */
 	errflag = 0;
@@ -926,6 +932,8 @@
 
     /* initialise the keymap system */
     init_keymaps();
+
+    varedarg = NULL;
 
     return 0;
 }
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Thu Apr 29 10:14:48 1999
+++ Src/Zle/zle_tricky.c	Thu Apr 29 10:40:14 1999
@@ -4280,14 +4280,22 @@
 
     if ((list = getshfunc(fn)) != &dummy_list) {
 	char **p, *tmp;
-	int set, aadd = 0, usea = 1, icf = incompfunc, osc = sfcontext;
+	int aadd = 0, usea = 1, icf = incompfunc, osc = sfcontext;
+	unsigned int set;
 	Param *ocpms = comppms;
 
 	comppms = (Param *) zalloc(CP_NUM * sizeof(Param));
 
-	set = -1 & ~(CP_PARAMETER | CP_REDIRECT | CP_QUOTE | CP_QUOTING |
-		     CP_EXACTSTR | CP_FORCELIST | CP_OLDLIST | CP_OLDINS |
-		     (useglob ? 0 : CP_PATMATCH));
+	set = CP_ALLMASK &
+	    ~(CP_PARAMETER | CP_REDIRECT | CP_QUOTE | CP_QUOTING |
+	      CP_EXACTSTR | CP_FORCELIST | CP_OLDLIST | CP_OLDINS |
+	      (useglob ? 0 : CP_PATMATCH));
+	zsfree(compvared);
+	if (varedarg) {
+	    compvared = ztrdup(varedarg);
+	    set |= CP_VARED;
+	} else
+	    compvared = ztrdup("");
 	if (!*complastprompt)
 	    set &= ~CP_LASTPROMPT;
 	zsfree(compcontext);
diff -u od/Zsh/compwid.yo Doc/Zsh/compwid.yo
--- od/Zsh/compwid.yo	Wed Apr 28 16:24:22 1999
+++ Doc/Zsh/compwid.yo	Thu Apr 29 11:05:07 1999
@@ -140,6 +140,12 @@
 )
 enditem()
 )
+item(tt(vared))(
+If completion is called while editing a line using the tt(vared)
+builtin, the value of this key is set to the name of the parameter
+given as argument to tt(vared). If tt(vared) is not currently used,
+this key is unset.
+)
 item(tt(parameter))(
 The name of the parameter when completing in a subscript or in the
 value of a parameter assignment.

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