Re: Completion problems.

Re: Completion problems.

[Sven Wischnowsky]

Tanaka Akira wrote:

> In article <199908021058.MAA12713@beta.informatik.hu-berlin.de>,
>   Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> > That's wrong, too. Again, this is a problem with the recently changed
> > quoting behaviour. The prefix is reported in quoted form and appended
> > and prepended to IPREFIX/ISUFFIX -- which will be quoted again when it 
> > is inserted.
> 
> Thanks. It is fixed.  But such a unquoting/re-quoting seems bit
> problematic with variables.
> 
> Z(3):akr@is27e1u11% Src/zsh -f
> is27e1u11% fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
> is27e1u11% _tst () { compset -P '*/'; compadd tst }
> is27e1u11% var=val
> is27e1u11% tst $var/<TAB>
> 
> Then, the last line is changed to:
> 
> is27e1u11% tst \$var/tst 

Ugh. Hm. Since compgen doesn't quote I{PRE,SUF}FIX, compadd shouldn't
do it, either (especially since the strings given with -[iI] aren't
quoted).
This patch tries to make the code use I*FIX as is in all cases.

(...and I still have to look into this multi-quoting thing for
compset-q/compctl-h, sigh.)

> I think automatic unquoting/re-quoting is dangerous.
> 
> Since the completion code works on quoted form and unquoted form is
> only interesting to usual completers, definitely the conversion
> between these forms is required. But it is sometimes very difficult or
> even impossible.
> 
> In following examples, unquoted forms are not known until runtime.
> 
> % if some-complex-command; then var=xxx; else var=yyy; fi; tst $var/<TAB>
> % tst $(some-complex-command)/<TAB>
> 
> So, I think that it is dangerous decision to embed the quoting stuff
> into the completion code.

(I'm not sure what you mean by `embed'.) The problem, err, one of the
problems with quoting and completion is that we have to call the lexer 
to get at the words from the line and then we have to live with what
the lexer gives us -- which is quoted. But for special contexts (such
as parameter expansions) we need to unquote (and probably tokenize) it 
to find out what's going on. Then we have to decide what we give to
the user, which currently is (or should be) the form from the
line. This is also important when it comes to comparing or matching
such strings, of course, and the globcomplete-behaviour comes into
play, too (where we even want the stuff from the line in tokenized
form).
We already had too much trouble with quoting in completion, so I'm
reluctant to change a state which has worked for some time.

I see two ways to go: 1) completely change the completion code to
report strings in unquoted form or 2) add a parameter expansion
modifier which does something like the opposite of `:q'.
Unfortunately, 1) is extremly hard and error-prone.

> I think that it is right way to separate the quoting stuff to builtin
> or variable expansion.

I don't understand you here, sorry. Oh, after reading further: do you
suggest something like the `opposite-of-:q'-thing or a builtin to work 
on quoted/unquoted strings?

> Also, I don't like re-quoting such as:
> 
> % tst a'#'/<TAB>
> ->
> % tst a\#/...
> 
> My expectation to completion is simply inserting something into cursor
> position. So re-quoting surprise me.  If the quoting stuff is
> separated, customizing these behaviours may be easier.

We can't really separate the quoting stuff, see above.

Also: changing a'#' to a\# is intentional and was discussed -- see
6400 and follow-ups (especially 6460 for this example). Even if
completion just inserts something new at the cursor position, this is
not necessarily the case. With completion functions like _path_files
and with match specs using `*'-patterns new stuff can be inserted
anywhere in the word. To retain the single quotes the completion code
would have to keep track of the original positions and would have to
calculate the new positions for every single or double quote inside
the word. This is extremly difficult, expensive (i.e. slow), and at
least I wouldn't implement it (if anyone else is interested: try to
find out how the completion code now handles completion inside braces
-- you would have to do something similar, but not only for two
places, but for a whole list of positions).

> Also, making the quoting stuff usable from completers is useful for
> checking the array words. For example, currentry, following does not
> work because contents of words are quoted form and $words[2] is
> "'-d'".
> 
> % cvs '-d' <TAB>
> 
> If _cvs can unquote the word safely, _cvs can determin options more
> precisely.

Yes, see above.

Bye
 Sven

diff -u os/Zle/compctl.c Src/Zle/compctl.c
--- os/Zle/compctl.c	Mon Aug  2 14:38:03 1999
+++ Src/Zle/compctl.c	Wed Aug  4 10:49:58 1999
@@ -1888,7 +1888,7 @@
     char *tmp, sav = compprefix[l];
 
     compprefix[l] = '\0';
-    tmp = tricat(compiprefix, rembslash(compprefix), "");
+    tmp = tricat(compiprefix, compprefix, "");
     zsfree(compiprefix);
     compiprefix = tmp;
     compprefix[l] = sav;
@@ -1903,7 +1903,7 @@
     char *tmp, sav;
 
     l = strlen(compsuffix) - l;
-    tmp = tricat(rembslash(compsuffix + l), compisuffix, "");
+    tmp = tricat(compsuffix + l, compisuffix, "");
     zsfree(compisuffix);
     compisuffix = tmp;
     sav = compsuffix[l];
@@ -2126,9 +2126,11 @@
     case CVT_RANGEPAT:
 	tokenize(sa);
 	sa = rembslash(sa);
+	remnulargs(sa);
 	if (sb) {
 	    tokenize(sb);
 	    sb = rembslash(sb);
+	    remnulargs(sb);
 	}
 	break;
     case CVT_PRENUM:
@@ -2144,6 +2146,7 @@
 	    na = -1;
 	tokenize(sa);
 	sa = rembslash(sa);
+	remnulargs(sa);
 	break;
     }
     return !do_comp_vars(test, na, sa, nb, sb, 1);
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Aug  2 14:38:04 1999
+++ Src/Zle/zle_tricky.c	Wed Aug  4 11:00:31 1999
@@ -3811,13 +3811,8 @@
 	    /* Get the contents of the completion variables if we have
 	     * to perform matching. */
 	    if (dat->aflags & CAF_MATCH) {
-		if (dat->aflags & CAF_QUOTE) {
-		    lipre = dupstring(compiprefix);
-		    lisuf = dupstring(compisuffix);
-		} else {
-		    lipre = quotename(compiprefix, NULL);
-		    lisuf = quotename(compisuffix, NULL);
-		}
+		lipre = dupstring(compiprefix);
+		lisuf = dupstring(compisuffix);
 		lpre = dupstring(compprefix);
 		lsuf = dupstring(compsuffix);
 		llpl = strlen(lpre);
@@ -5030,8 +5025,6 @@
 	remnulargs(p);
 	ctokenize(s);
 	remnulargs(s);
-	ctokenize(ip);
-	remnulargs(ip);
     }
     lp = strlen(p);
     ls = strlen(s);

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

Re: Completion problems.

[Bart Schaefer]

On Aug 4, 11:37am, Sven Wischnowsky wrote:
} Subject: Re: Completion problems.
}
} Tanaka Akira wrote:
} 
} > In following examples, unquoted forms are not known until runtime.
} > 
} > % if some-complex-command; then var=xxx; else var=yyy; fi; tst $var/<TAB>
} > % tst $(some-complex-command)/<TAB>
} 
} I see two ways to go: 1) completely change the completion code to
} report strings in unquoted form or 2) add a parameter expansion
} modifier which does something like the opposite of `:q'.

I think (2) would be quite useful in other contexts anyway.  Perhaps (Q)?
(And we could add (q) which means the same as :q, just for completeness.)

There is some question about what paramter unquoting should do in the case
of mismatched quotes.  I can think of cases where you'd want it to produce
the same errors as using that same quoting in a command, and other cases
(like completion) where you'd just like it to assume the closing quote.

} [...] with match specs using `*'-patterns new stuff can be inserted
} anywhere in the word. To retain the single quotes the completion code
} would have to keep track of the original positions and would have to
} calculate the new positions for every single or double quote inside
} the word. This is extremly difficult, expensive (i.e. slow), and at
} least I wouldn't implement it (if anyone else is interested: try to
} find out how the completion code now handles completion inside braces
} -- you would have to do something similar, but not only for two
} places, but for a whole list of positions).

I almost hate to mention this, but braces can be nested, and right now
completion doesn't work in that case -- presumably *because* it isn't
keeping track of a list of positions.

There are similar (?) problems with nested parameter substitutions:

zagzig<1> echo ${${p<TAB>
path     perl     prompt   psvar           
zagzig<1> echo ${${pa<TAB>
zagzig<1> echo ${${path} 
                         ^Cursor is now here; arguably no space should
                          have been added, because it can't possibly be
                          correct in that context.  Also, if you now type
                          a right-curly, the trailing space is deleted,
                          but the right-curly is not inserted (which I
                          guess is theoretically correct).

BTW, expand-or-complete is a pain in the butt when combined with braces,
because as soon as you close the braces the next TAB *expands* them,
leaving you with multiple half-finished words.  You can prevent this by
setting GLOB_COMPLETE, but in that case completion after the right-brace
still doesn't work.

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

Re: Completion problems.

[Tanaka Akira]

In article <199908040937.LAA15313@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> I see two ways to go: 1) completely change the completion code to
> report strings in unquoted form or 2) add a parameter expansion
> modifier which does something like the opposite of `:q'.
> Unfortunately, 1) is extremly hard and error-prone.

I think that (1) is right way though I didn't know it's extremly hard
because I'm not know the code internal well.

(2) is good and it is required for implementation of completers if (1)
is realized. But it is also useful for current completers. Thanks.

> I don't understand you here, sorry. Oh, after reading further: do you
> suggest something like the `opposite-of-:q'-thing or a builtin to work 
> on quoted/unquoted strings?

Yes.
# Sorry for my bad English.

> Also: changing a'#' to a\# is intentional and was discussed -- see
> 6400 and follow-ups (especially 6460 for this example). 

Ok, I understand. I didn't think match specs.  But... is this
intentional?

Z:akr@is27e1u11% zsh-3.1.6-pws-1 -f
is27e1u11% autoload -U compinit; compinit -D; compdef _tst tst
is27e1u11% _tst () { compset -P '*/'; compadd tst }
is27e1u11% var=val
is27e1u11% tst 'a'$var/<TAB>

-> 

is27e1u11% tst 'a$var/tst' 

# My reply may be slow, since I'm bit busy now, 
-- 
Tanaka Akira

Re: Completion problems.

[Sven Wischnowsky]

Tanaka Akira wrote:

> In article <199908040937.LAA15313@beta.informatik.hu-berlin.de>,
>   Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> > I see two ways to go: 1) completely change the completion code to
> > report strings in unquoted form or 2) add a parameter expansion
> > modifier which does something like the opposite of `:q'.
> > Unfortunately, 1) is extremly hard and error-prone.
> 
> I think that (1) is right way though I didn't know it's extremly hard
> because I'm not know the code internal well.

I still don't think that 1) is the right thing to do because some day
someone might come and want to be able to see which words are
quoted. Reporting them as they appear on the line is the only way to
achieve this and together with the Q modifier/flag one can always get
at the unquoted forms.

> > Also: changing a'#' to a\# is intentional and was discussed -- see
> > 6400 and follow-ups (especially 6460 for this example). 
> 
> Ok, I understand. I didn't think match specs.  But... is this
> intentional?
> 
> Z:akr@is27e1u11% zsh-3.1.6-pws-1 -f
> is27e1u11% autoload -U compinit; compinit -D; compdef _tst tst
> is27e1u11% _tst () { compset -P '*/'; compadd tst }
> is27e1u11% var=val
> is27e1u11% tst 'a'$var/<TAB>
> 
> -> 
> 
> is27e1u11% tst 'a$var/tst' 

Yes, it is, err, no it isn't, err -- well I didn't think about the
possibility of $var stuff after the closing quote.


In a message with a completely different Subject Andrej Borsenkow wrote:

> bor@itsrm2:~%> zsh -f
> itsrm2% autoload compinit;compinit -D
> itsrm2% l /t/b/{zsh<TAB>
> itsrm2% l /tool{s/bin/zsh
>               ^^^
> Note, that the brace was (re)inserted at the old place. If I now try to insert
> something with accept-and-menu-complete, it will correctly insert the
> ``s/bin/zsh-xxx'' - but, it is rather unexpected. And, users will probably
> expect, that they simply can type in ``,zsh.old,zsh-what-ever}'' - and this does
> not work any more.

We lost it when we made _path_files do the matching via -D and add the 
matches with -U. This *is* a problem, because with -U the code can't
know where to re-insert the braces. Trying to fix this by using
matching compadds to add the matches revealed that the code also has
problems when the braces are in the path-prefix/suffix under certain
circumstances.


Ok, in the light of these two and the problem that we still can't
complete inside nested braces mentioned by Bart and the multi-quote
problem I keep alluding to I'd say that maybe I should have a look at
all of these together. That'll take a while, though.

Bye
 Sven


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

Re: Completion problems.

[Sven Wischnowsky]

Bart Schaefer wrote:

> I think (2) would be quite useful in other contexts anyway.  Perhaps (Q)?
> (And we could add (q) which means the same as :q, just for completeness.)

;-) I've been thinking about (q), too.

> There is some question about what paramter unquoting should do in the case
> of mismatched quotes.  I can think of cases where you'd want it to produce
> the same errors as using that same quoting in a command, and other cases
> (like completion) where you'd just like it to assume the closing quote.

Right. Maybe I'll find some time soon...

> } [...] with match specs using `*'-patterns new stuff can be inserted
> } anywhere in the word. To retain the single quotes the completion code
> } would have to keep track of the original positions and would have to
> } calculate the new positions for every single or double quote inside
> } the word. This is extremly difficult, expensive (i.e. slow), and at
> } least I wouldn't implement it (if anyone else is interested: try to
> } find out how the completion code now handles completion inside braces
> } -- you would have to do something similar, but not only for two
> } places, but for a whole list of positions).
> 
> I almost hate to mention this, but braces can be nested, and right now
> completion doesn't work in that case -- presumably *because* it isn't
> keeping track of a list of positions.

I didn't write the original in-brace-completion-code, but I think it
was done in the way it was done mainly because `a{b<TAB>' is
relatively easy to parse and there is only one possible prefix to
complete whereas with `a{b{c' we would have to collect multiple parts
of the string to complete (instead of just removing a bit) and with
`a{b,c}d{e<TAB>' we would have to handle both `abde' and `acde', of
course. At the time completion in braces was added the code only
inserted a prefix and/or a suffix at the cursor position so there
wasn't a problem with keeping a list of positions.

Do you want to say that completion in nested braces should be
possible? (Horrors. But, yes, maybe it should be...)

> There are similar (?) problems with nested parameter substitutions:
> 
> zagzig<1> echo ${${p<TAB>
> path     perl     prompt   psvar           
> zagzig<1> echo ${${pa<TAB>
> zagzig<1> echo ${${path} 
>                          ^Cursor is now here; arguably no space should
>                           have been added, because it can't possibly be
>                           correct in that context.  Also, if you now type
>                           a right-curly, the trailing space is deleted,
>                           but the right-curly is not inserted (which I
>                           guess is theoretically correct).

Completion inside parameter expansions is a different thing because
there we only look at the name and ignore the surrounding parts of the 
string.
The patch below makes the code check for nested parameter expansions
and not insert a space then. The algorithm for testing for nested
expansions is very simple, but I think it should get most things
right.
The patch also makes `}' remove the suffix for completion after
`${...' in the new completion stuff and avoid the space on nested
expansions there, too.
Btw. did you all know that the new completion code currently doesn't
respect AUTO_PARAM_SLASH? I knew, but didn't tell anyone. Naughty me.

> BTW, expand-or-complete is a pain in the butt when combined with braces,
> because as soon as you close the braces the next TAB *expands* them,
> leaving you with multiple half-finished words.  You can prevent this by
> setting GLOB_COMPLETE, but in that case completion after the right-brace
> still doesn't work.

See above -- completion after a closed `{a,b}' would be something
completely new: multiple prefixes. We would have to generate multiple
sets of matches and then select those present in all sets.

Bye
 Sven

diff -u os/Zle/comp.h Src/Zle/comp.h
--- os/Zle/comp.h	Mon Aug  2 11:44:52 1999
+++ Src/Zle/comp.h	Thu Aug  5 10:47:52 1999
@@ -227,7 +227,8 @@
 #define CMF_FILE     1		/* this is a file */
 #define CMF_REMOVE   2		/* remove the suffix */
 #define CMF_PARBR    4		/* paramter expansion with a brace */
-#define CMF_NOLIST   8		/* should not be listed */
+#define CMF_PARNEST  8		/* nested paramter expansion */
+#define CMF_NOLIST  16		/* should not be listed */
 
 
 /* Stuff for completion matcher control. */
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Wed Aug  4 11:38:31 1999
+++ Src/Zle/zle_tricky.c	Thu Aug  5 10:55:33 1999
@@ -728,7 +728,7 @@
     if ((*p == String || *p == Qstring) && p[1] != Inpar && p[1] != Inbrack) {
 	/* This is really a parameter expression (not $(...) or $[...]). */
 	char *b = p + 1, *e = b;
-	int n = 0, br = 1;
+	int n = 0, br = 1, nest = 0;
 
 	if (*b == Inbrace) {
 	    char *tb = b;
@@ -740,6 +740,10 @@
 	    /* Ignore the possible (...) flags. */
 	    b++, br++;
 	    n = skipparens(Inpar, Outpar, &b);
+
+	    for (tb = p - 1; tb > s && *tb != Outbrace && *tb != Inbrace; tb--);
+	    if (tb > s && *tb == Inbrace && (tb[-1] == String || *tb == Qstring))
+		nest = 1;
 	}
 
 	/* Ignore the stuff before the parameter name. */
@@ -788,9 +792,11 @@
 	     * global variables. */
 
 	    if (set) {
-		if (br >= 2)
+		if (br >= 2) {
 		    mflags |= CMF_PARBR;
-
+		    if (nest)
+			mflags |= CMF_PARNEST;
+		}
 		/* Get the prefix (anything up to the character before the name). */
 		isuf = dupstring(e);
 		untokenize(isuf);
@@ -7728,6 +7734,8 @@
 	    minfo.insc++;
 	    if (minfo.we)
 		minfo.end += minfo.insc;
+	    if (m->flags & CMF_PARNEST)
+		havesuff = 1;
 	}
 	if ((m->flags & CMF_FILE) || (m->ripre && isset(AUTOPARAMSLASH))) {
 	    /* If we have a filename or we completed a parameter name      *
@@ -7741,11 +7749,12 @@
 		t = 1;
 	    else {
 		/* Build the path name. */
-		if (m->ripre && !*psuf) {
+		if (m->ripre && !*psuf && !(m->flags & CMF_PARNEST)) {
 		    int ne = noerrs;
 
-		    p = (char *) zhalloc(strlen(m->ripre) + strlen(str) + 1);
-		    sprintf(p, "%s%s", m->ripre, str);
+		    p = (char *) zhalloc(strlen(m->ripre) + strlen(str) + 2);
+		    sprintf(p, "%s%s%c", m->ripre, str,
+			    ((m->flags & CMF_PARBR) ? Outbrace : '\0'));
 		    noerrs = 1;
 		    parsestr(p);
 		    singsub(&p);
diff -u oc/Base/_brace_parameter Completion/Base/_brace_parameter
--- oc/Base/_brace_parameter	Mon Aug  2 11:45:10 1999
+++ Completion/Base/_brace_parameter	Thu Aug  5 11:00:29 1999
@@ -7,6 +7,8 @@
 if [[ "$SUFFIX" = *\}* ]]; then
   ISUFFIX="${SUFFIX#*\}}$ISUFFIX"
   SUFFIX="${SUFFIX%%\}*}"
+elif [[ "$LBUFFER" = *\$\{[^}]#\$\{[^}]#$PREFIX ]]; then
+  suf='}'
 else
   suf='} '
 fi
@@ -18,4 +20,4 @@
 
 [[ n -gt 0 ]] && suf=''
 
-_parameters -Qs "${q[1,-n-1]}" -S "$suf" -r '-:?#%+=[/'
+_parameters -Qs "${q[1,-n-1]}" -S "$suf" -r '-:?#%+=[/}'

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

Re: Completion problems.

[Sven Wischnowsky]

I wrote:

> The problem was that cond_str() always returned an
> untokenized string. The patch gives a new argument to it which may be
> non-zero to get the tokenized form.

I forgot to include the diff for Modules/example.c. Sorry.

Bye
 Sven

diff -u os/Modules/example.c Src/Modules/example.c
--- os/Modules/example.c	Tue Aug  3 08:57:51 1999
+++ Src/Modules/example.c	Tue Aug  3 08:58:21 1999
@@ -80,7 +80,7 @@
 static int
 cond_p_len(char **a, int id)
 {
-    char *s1 = cond_str(a, 0);
+    char *s1 = cond_str(a, 0, 0);
 
     if (a[1]) {
 	zlong v = cond_val(a, 1);
@@ -95,7 +95,7 @@
 static int
 cond_i_ex(char **a, int id)
 {
-    char *s1 = cond_str(a, 0), *s2 = cond_str(a, 1);
+    char *s1 = cond_str(a, 0, 0), *s2 = cond_str(a, 1, 0);
 
     return !strcmp("example", dyncat(s1, s2));
 }

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

Re: Completion problems.

[Tanaka Akira]

In article <199908021058.MAA12713@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> That's wrong, too. Again, this is a problem with the recently changed
> quoting behaviour. The prefix is reported in quoted form and appended
> and prepended to IPREFIX/ISUFFIX -- which will be quoted again when it 
> is inserted.

Thanks. It is fixed.  But such a unquoting/re-quoting seems bit
problematic with variables.

Z(3):akr@is27e1u11% Src/zsh -f
is27e1u11% fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
is27e1u11% _tst () { compset -P '*/'; compadd tst }
is27e1u11% var=val
is27e1u11% tst $var/<TAB>

Then, the last line is changed to:

is27e1u11% tst \$var/tst 

I think automatic unquoting/re-quoting is dangerous.

Since the completion code works on quoted form and unquoted form is
only interesting to usual completers, definitely the conversion
between these forms is required. But it is sometimes very difficult or
even impossible.

In following examples, unquoted forms are not known until runtime.

% if some-complex-command; then var=xxx; else var=yyy; fi; tst $var/<TAB>
% tst $(some-complex-command)/<TAB>

So, I think that it is dangerous decision to embed the quoting stuff
into the completion code.

I think that it is right way to separate the quoting stuff to builtin
or variable expansion.

Also, I don't like re-quoting such as:

% tst a'#'/<TAB>
->
% tst a\#/...

My expectation to completion is simply inserting something into cursor
position. So re-quoting surprise me.  If the quoting stuff is
separated, customizing these behaviours may be easier.

Also, making the quoting stuff usable from completers is useful for
checking the array words. For example, currentry, following does not
work because contents of words are quoted form and $words[2] is
"'-d'".

% cvs '-d' <TAB>

If _cvs can unquote the word safely, _cvs can determin options more
precisely.
(Although we can use eval, I think eval is evil.)
-- 
Tanaka Akira

Re: Completion problems.

[Sven Wischnowsky]

Tanaka Akira wrote:

> I found a problem about the conditional expression for completion.
> 
> is27e1u11% autoload -U compinit; compinit -D
> is27e1u11% _tst () { if [[ -prefix */ ]]; then compadd ../t; else compadd ../f; fi }
> is27e1u11% compdef _tst tst
> is27e1u11% tst ../<TAB>
> 
> Then, I get:
> 
> is27e1u11% tst ../f 
> 
> I think it should be "../t ".

Definitely, yes. The problem was that cond_str() always returned an
untokenized string. The patch gives a new argument to it which may be
non-zero to get the tokenized form. Then there were some missing tests 
for `if (mod)' in do_comp_vars() (mod says if the special parameters
should be modified). Some of the new tests are superfluous for the
condition codes we have now, but if someone once changes this, the
tests will already be there.

> Hm. compset -P is bit dangerous for quoted characters.
> 
> is27e1u11% autoload -U compinit; compinit -D
> is27e1u11% _tst () { compset -P '*/'; compadd tst }
> is27e1u11% compdef _tst tst
> is27e1u11% tst \#/<TAB>
> 
> Then, I get:
> 
> is27e1u11% tst \\\#/tst 

That's wrong, too. Again, this is a problem with the recently changed
quoting behaviour. The prefix is reported in quoted form and appended
and prepended to IPREFIX/ISUFFIX -- which will be quoted again when it 
is inserted.

Bye
 Sven

diff -u os/cond.c Src/cond.c
--- os/cond.c	Mon Aug  2 11:44:45 1999
+++ Src/cond.c	Mon Aug  2 11:56:31 1999
@@ -303,12 +303,13 @@
 
 /**/
 char *
-cond_str(char **args, int num)
+cond_str(char **args, int num, int raw)
 {
     char *s = args[num];
 
     singsub(&s);
-    untokenize(s);
+    if (!raw)
+	untokenize(s);
 
     return s;
 }
diff -u os/Zle/compctl.c Src/Zle/compctl.c
--- os/Zle/compctl.c	Mon Aug  2 11:44:52 1999
+++ Src/Zle/compctl.c	Mon Aug  2 12:51:28 1999
@@ -1888,7 +1888,7 @@
     char *tmp, sav = compprefix[l];
 
     compprefix[l] = '\0';
-    tmp = tricat(compiprefix, compprefix, "");
+    tmp = tricat(compiprefix, rembslash(compprefix), "");
     zsfree(compiprefix);
     compiprefix = tmp;
     compprefix[l] = sav;
@@ -1903,7 +1903,7 @@
     char *tmp, sav;
 
     l = strlen(compsuffix) - l;
-    tmp = tricat(compsuffix + l, compisuffix, "");
+    tmp = tricat(rembslash(compsuffix + l), compisuffix, "");
     zsfree(compisuffix);
     compisuffix = tmp;
     sav = compsuffix[l];
@@ -1947,8 +1947,8 @@
 
 	    if (compcurrent - 1 < na || compcurrent - 1 > nb)
 		return 0;
-
-	    restrict_range(na, nb);
+	    if (mod)
+		restrict_range(na, nb);
 	    return 1;
 	}
     case CVT_RANGEPAT:
@@ -1989,7 +1989,7 @@
 	    }
 	    if (e < b)
 		t = 0;
-	    if (t)
+	    if (t && mod)
 		restrict_range(b, e);
 	    return t;
 	}
@@ -2043,8 +2043,8 @@
 		}
 		if (!l)
 		    return 0;
-
-		ignore_prefix(p - compprefix);
+		if (mod)
+		    ignore_prefix(p - compprefix);
 	    } else {
 		int l, ol, add;
 		char *p;
@@ -2065,8 +2065,8 @@
 
 		if (!l)
 		    return 0;
-
-		ignore_suffix(ol - (p - compsuffix));
+		if (mod)
+		    ignore_suffix(ol - (p - compsuffix));
 	    }
 	    return 1;
 	}
@@ -2469,10 +2469,10 @@
 {
     if (comp_check()) {
 	if (a[1])
-	    return do_comp_vars(id, cond_val(a, 0), cond_str(a, 1),
+	    return do_comp_vars(id, cond_val(a, 0), cond_str(a, 1, 1),
 				0, NULL, 0);
 	else
-	    return do_comp_vars(id, -1, cond_str(a, 0), 0, NULL, 0);
+	    return do_comp_vars(id, -1, cond_str(a, 0, 1), 0, NULL, 0);
     }
     return 0;
 }
@@ -2481,8 +2481,8 @@
 static int
 cond_range(char **a, int id)
 {
-    return do_comp_vars(CVT_RANGEPAT, 0, cond_str(a, 0), 0,
-			(id ? cond_str(a, 1) : NULL), 0);
+    return do_comp_vars(CVT_RANGEPAT, 0, cond_str(a, 0, 1), 0,
+			(id ? cond_str(a, 1, 1) : NULL), 0);
 }
 
 static struct builtin bintab[] = {
--- Util/zsh-development-guide.old	Mon Aug  2 11:58:18 1999
+++ Util/zsh-development-guide	Mon Aug  2 11:59:03 1999
@@ -285,11 +285,12 @@
 no substitutions are performed on them and that they will be
 tokenized. There are three helper functions available:
 
-  - char *cond_str(args, num)
+  - char *cond_str(args, num, raw)
     The first argument is the array of strings the handler function
     got as an argument and the second one is an index into this array.
     The return value is the num'th string from the array with
-    substitutions performed and untokenized.
+    substitutions performed. If the last argument is zero, the string
+    will also be untokenized.
   - long cond_val(args, num)
     The arguments are the same as for cond_str(). The return value is
     the result of the mathematical evaluation of the num'th string

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

Completion problems.

[Tanaka Akira]

I found a problem about the conditional expression for completion.

is27e1u11% autoload -U compinit; compinit -D
is27e1u11% _tst () { if [[ -prefix */ ]]; then compadd ../t; else compadd ../f; fi }
is27e1u11% compdef _tst tst
is27e1u11% tst ../<TAB>

Then, I get:

is27e1u11% tst ../f 

I think it should be "../t ".
-- 
Tanaka Akira

Re: completion problems.

[Vin Shelton]

akr@jaist.ac.jp said:
> # 6104 is rejected. Hmm.
> This is a display-bug I can reproduce, but... Geoff? 

You need to unapply 6101 before applying 6104.

  - vin

Re: completion problems.

[Tanaka Akira]

In article <199904271612.SAA16038@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Fixed by the patch below. Ahem. Sorry.

Thank you.

This patch (with patches from
zsh-workers:6105,6106,6109,6113,6117,6118,6119,6121) fix the problem.

# 6104 is rejected. Hmm.

> This is a display-bug I can reproduce, but... Geoff?

I remember that sometimes ago I installed latest kterm but I didn't
update termcap database.

After I install latest kterm/xterm entry for termcap, this problem is
fixed.
-- 
Tanaka Akira

Re: completion problems.

[Sven Wischnowsky]

Tanaka Akira wrote:

> I found two problems in completion with zsh-3.1.5-pws-16.
> 
> (1) zsh does not complete second candidate.
> ...
> Push TAB on after "ls ", then files in current directory is listed.
> ...
> Push TAB again, then "ChangeLog" is completed.
> ...
> Push TAB again and agen, nothing are changed.

Fixed by the patch below. Ahem. Sorry.

This was caused by a wrong test -- the one I moved to get _oldlist to
work. While playing with that, I also discovered another bug where the 
completion code thought it still were in menucompletion but didn't
even have a valid list anymore.

Also, while trying to test it with _oldlist, I found out that it
needed a little change (I have complete-word bound to TAB).

> Push TAB, then file list and "c" is cleared and "onfig" is completed.
> 
> rascal% ls  onfig
> 
> Push Ctrl-L, then screen is cleared and following line is appeared on
> top of screen.

This is a display-bug I can reproduce, but... Geoff?

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Apr 27 15:38:11 1999
+++ Src/Zle/zle_tricky.c	Tue Apr 27 17:57:49 1999
@@ -760,8 +760,8 @@
 
     /* If we are doing a menu-completion... */
 
-    if (menucmp && lst != COMP_LIST_EXPAND && compwidget &&
-	compwidget == lastcompwidget) {
+    if (menucmp && lst != COMP_LIST_EXPAND && 
+	(!compwidget || compwidget == lastcompwidget)) {
 	do_menucmp(lst);
 	return;
     }
@@ -4598,6 +4598,7 @@
 	insmnum = insgnum = 1;
 	insgroup = oldlist = oldins = 0;
 	begcmgroup("default", 0);
+	menucmp = 0;
 
 	ccused = newlinklist();
 	ccstack = newlinklist();
diff -u oc/Core/_oldlist Completion/Core/_oldlist
--- oc/Core/_oldlist	Tue Apr 27 18:06:54 1999
+++ Completion/Core/_oldlist	Tue Apr 27 18:06:59 1999
@@ -15,7 +15,7 @@
 # If this is a completion widget, and we have a completion inserted already,
 # and the compconfig key oldlist_menu is not never, then we cycle through the
 # existing list (even if it was generated by another widget).
-if [[ -n $compstate[old_insert] && $WIDGET = *complete(|-prefix) &&
+if [[ -n $compstate[old_insert] && $WIDGET = *complete(|-prefix|-word) &&
   $compconfig[oldlist_menu] != never ]]; then
   compstate[old_list]=keep
   if [[ $WIDGET = *reverse* ]]; then

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

completion problems.

[Tanaka Akira]

I found two problems in completion with zsh-3.1.5-pws-16.

(1) zsh does not complete second candidate.

Z(2):akr@is27e1u11% ls
ChangeLog      INSTALL        StartupFiles   config.h       install-sh
ChangeLog.3.0  META-FAQ       Util           config.h.in    mkinstalldirs
Completion     Makefile       acconfig.h     config.log     patchlist.txt
Config         Makefile.in    aclocal.m4     config.status  stamp-h
Doc            Misc           aczsh.m4       config.sub     stamp-h.in
Etc            README         config.cache   configure
Functions      Src            config.guess   configure.in
Z(2):akr@is27e1u11% ./Src/zsh -f
is27e1u11% echo $ZSH_VERSION 
3.1.5-pws-16
is27e1u11% ls 

Push TAB on after "ls ", then files in current directory is listed.

is27e1u11% ls 
ChangeLog       INSTALL         StartupFiles/   config.h        install-sh*
ChangeLog.3.0   META-FAQ        Util/           config.h.in     mkinstalldirs*
Completion/     Makefile        acconfig.h      config.log      patchlist.txt 
Config/         Makefile.in     aclocal.m4      config.status*  stamp-h 
Doc/            Misc/           aczsh.m4        config.sub*     stamp-h.in 
Etc/            README          config.cache    configure*      
Functions/      Src/            config.guess*   configure.in    

Push TAB again, then "ChangeLog" is completed.

is27e1u11% ls ChangeLog
ChangeLog       INSTALL         StartupFiles/   config.h        install-sh*
ChangeLog.3.0   META-FAQ        Util/           config.h.in     mkinstalldirs*
Completion/     Makefile        acconfig.h      config.log      patchlist.txt 
Config/         Makefile.in     aclocal.m4      config.status*  stamp-h 
Doc/            Misc/           aczsh.m4        config.sub*     stamp-h.in 
Etc/            README          config.cache    configure*      
Functions/      Src/            config.guess*   configure.in    

Push TAB again and agen, nothing are changed.

I expect that "ChangeLog.3.0" will be completed and pws-15 behaves so.

(2) zsh sometimes clear character in command line on BSD/OS 3.0.

Z(2):akr@rascal% ls
ChangeLog       INSTALL         StartupFiles    config.h        install-sh
ChangeLog.3.0   META-FAQ        Util            config.h.in     mkinstalldirs
Completion      Makefile        acconfig.h      config.log      patchlist.txt
Config          Makefile.in     aclocal.m4      config.status   stamp-h
Doc             Misc            aczsh.m4        config.sub      stamp-h.in
Etc             README          config.cache    configure
Functions       Src             config.guess    configure.in
Z(2):akr@rascal% ./Src/zsh -f
rascal% echo $ZSH_VERSION
3.1.5-pws-16
rascal% ls 

Push TAB after "ls ".

rascal% ls 
ChangeLog       INSTALL         StartupFiles/   config.h        install-sh*
ChangeLog.3.0   META-FAQ        Util/           config.h.in     mkinstalldirs*
Completion/     Makefile        acconfig.h      config.log      patchlist.txt 
Config/         Makefile.in     aclocal.m4      config.status*  stamp-h 
Doc/            Misc/           aczsh.m4        config.sub*     stamp-h.in 
Etc/            README          config.cache    configure*      
Functions/      Src/            config.guess*   configure.in    

Push "c".

rascal% ls c
ChangeLog       INSTALL         StartupFiles/   config.h        install-sh*
ChangeLog.3.0   META-FAQ        Util/           config.h.in     mkinstalldirs*
Completion/     Makefile        acconfig.h      config.log      patchlist.txt 
Config/         Makefile.in     aclocal.m4      config.status*  stamp-h 
Doc/            Misc/           aczsh.m4        config.sub*     stamp-h.in 
Etc/            README          config.cache    configure*      
Functions/      Src/            config.guess*   configure.in    

Push TAB, then file list and "c" is cleared and "onfig" is completed.

rascal% ls  onfig

Push Ctrl-L, then screen is cleared and following line is appeared on
top of screen.

rascal% ls config

typescript is follows.

begin 644 typescript
M4V-R:7!T('-T87)T960@;VX@5'5E($%P<B`R-R`R,SHR,#HR,R`Q.3DY"@T;
M6VT;6VT;6VT;6THD(!M;2RX(+B]3<F,O>G-H("UF#0T*#1M;;1M;;1M;;1M;
M2G)A<V-A;"4@&UM+;`AL<R`-#0I#:&%N9V5,;V<@("`@("`@1&]C+R`@("`@
M("`@("`@($U%5$$M1D%1("`@("`@("!214%$344@("`@("`@("`@86-C;VYF
M:6<N:"`@("`@(&-O;F9I9RYG=65S<RH@("!C;VYF:6<N<W1A='5S*B`@:6YS
M=&%L;"US:"H@("`@('-T86UP+6@N:6X@#0I#:&%N9V5,;V<N,RXP("`@171C
M+R`@("`@("`@("`@($UA:V5F:6QE("`@("`@("!3<F,O("`@("`@("`@("`@
M86-L;V-A;"YM-"`@("`@(&-O;F9I9RYH("`@("`@("!C;VYF:6<N<W5B*B`@
M("`@;6MI;G-T86QL9&ER<RH@('1Y<&5S8W)I<'0@#0I#;VUP;&5T:6]N+R`@
M("`@1G5N8W1I;VYS+R`@("`@($UA:V5F:6QE+FEN("`@("!3=&%R='5P1FEL
M97,O("`@86-Z<V@N;30@("`@("`@(&-O;F9I9RYH+FEN("`@("!C;VYF:6=U
M<F4J("`@("`@<&%T8VAL:7-T+G1X="`@(`T*0V]N9FEG+R`@("`@("`@($E.
M4U1!3$P@("`@("`@("!-:7-C+R`@("`@("`@("`@571I;"\@("`@("`@("`@
M(&-O;F9I9RYC86-H92`@("!C;VYF:6<N;&]G("`@("`@8V]N9FEG=7)E+FEN
M("`@('-T86UP+6@@("`@("`@("`;6S1!&UMM&UMM&UMM#7)A<V-A;"4@;',@
M!V,-#0H;6TH;6T%R87-C86PE(&QS("!O;F9I9PT-"AM;2@T;6VT;6VT;6VT;
M6TIR87-C86PE(!M;2PT-"@T;6VT;6VT;6VT;6THD(!M;2PT-"@I38W)I<'0@
A9&]N92!O;B!4=64@07!R(#(W(#(S.C(P.C,Y(#$Y.3D*
`
end

On BSD/OS 3.0, pws-14 has no problem but pws-15 and pws-16 has this
problem.

On Solaris 7, There is no problem even in pws-15 or pws-16.
-- 
Tanaka Akira