PATCH: tricky.c (was messages from Andrej and Bart)

PATCH: tricky.c (was messages from Andrej and Bart)

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> with all but a-a-m-c patches (upto 5714):
> 
> bor@itsrm2:/tools/src/zsh-3.1.5-pws-11%> ./configure --p=/to<TAB>
> bor@itsrm2:/tools/src/zsh-3.1.5-pws-11%> ./configure --pr=/to
>                                                          ^ cursor here
> (after --pr)
> 
>    now I add `e'
> bor@itsrm2:/tools/src/zsh-3.1.5-pws-11%> ./configure --pre=/to<TAB>
>                                                           ^ cursor here
> (after --pre)
> bor@itsrm2:/tools/src/zsh-3.1.5-pws-11%> ./configure --prefix}tools/to

A little oversight in the test in `ctokenize()'.


Bart Schaefer wrote:

> Using 3.1.5-pws-11 with the patches Sven posted overnight (well, overnight
> US Pacific Time) 3/8-3/9, I get this strange behavior:
> 
> zsh% fpath=($PWD:h<TAB>
> zsh% fpath=(src/  
> 
> I expected to get "fpath=(/home/schaefer/src/" ...

That one is a poser... `expand-or-complete' never expanded this
without braces. If it expanded it, it wouldn't add a trailing slash
(but instead add a space, try `${PWD:h}<TAB>'). So this is handled by
the completion code. There, it expands the `$PWD:h', gets a path from
it, and then tries to complete the last pathname component. So I think 
the best solution would be to add a slash (and leave the line
otherwise untouched). BUT I have no idea how I can get the code to do
this... The problem is that after expansion, the code can't find out
what came from the expansion in cases like `${foo}x<TAB>'. So the
patch just uses the expanded prefix if it has the problem that the
expanded prefix contains slashes and the original string doesn't.
Maybe a better solution would be to do nothing in such cases.

The patch also contains a small cleanup in `acceptandmenucomplete()',
making `iremovesuffix()' be called when no brace expansion prefix was
collected.


Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Mar  9 15:56:56 1999
+++ Src/Zle/zle_tricky.c	Wed Mar 10 10:11:35 1999
@@ -471,11 +475,8 @@
 	brbeg[l] = ',';
 	brbeg[l + 1] = '\0';
     } else {
-	int sl = suffixlen[' '];
-
 	cs = menupos + menulen + menuinsc;
-	if (sl)
-	    backdel(sl);
+	iremovesuffix(' ', 1);
 
 	inststrlen(" ", 1, 1);
 	menuinsc = menulen = 0;
@@ -5443,7 +5444,7 @@
 	if (*p == '\\')
 	    bslash = 1;
 	else {
-	    if (*p == '$' || *p == '=' || *p == '{' || *p == '}') {
+	    if (*p == '$' || *p == '{' || *p == '}') {
 		if (bslash)
 		    p[-1] = Bnull;
 		else
@@ -6198,9 +6199,12 @@
 	    if ((p = strrchr(lppre, '/'))) {
 		p[1] = '\0';
 		lppl = strlen(lppre);
-	    } else {
+	    } else if (!sf1) {
 		lppre = NULL;
 		lppl = 0;
+	    } else {
+		lppre = ppre;
+		lppl = strlen(lppre);
 	    }
 	} else {
 	    lppre = NULL;
@@ -6217,7 +6221,8 @@
 
 		strcpy(p, p + strlen(brend));
 	    }
-	    lpsuf = strchr(lpsuf, '/');
+	    if (!(lpsuf = strchr(lpsuf, '/')) && sf2)
+		lpsuf = psuf;
 	    lpsl = (lpsuf ? strlen(lpsuf) : 0);
 	} else {
 	    lpsuf = NULL;

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

Re: PATCH: tricky.c (was messages from Andrej and Bart)

[Bart Schaefer]

Sven Wischnowsky writes:
 > 
 > Bart Schaefer wrote:
 > 
 > > Using 3.1.5-pws-11 with the patches Sven posted overnight (well, overnight
 > > US Pacific Time) 3/8-3/9, I get this strange behavior:
 > > 
 > > zsh% fpath=($PWD:h<TAB>
 > > zsh% fpath=(src/  
 > > 
 > > I expected to get "fpath=(/home/schaefer/src/" ...
 > 
 > That one is a poser... `expand-or-complete' never expanded this
 > without braces.

Ah ... you're right.  That would actually be fine, too (keep the old
behavior of it simply feeping on the above input); but it's completely
wrong to have it replace the input with a fragment of the parameter's
value.

 > If it expanded it, it wouldn't add a trailing slash
 > (but instead add a space, try `${PWD:h}<TAB>').

Yes, I know.

 > So this is handled by the completion code. There, it expands the
 > `$PWD:h', gets a path from it, and then tries to complete the last
 > pathname component.

Yes, but there isn't anything to which that last component should have
completed (there was no subdirectory "src" of the current directory).

 > The problem is that after expansion, the code can't find out
 > what came from the expansion in cases like `${foo}x<TAB>'.

Hrm ... so what was happening in the old completion code in this case?

 > So the patch just uses the expanded prefix if it has the problem that
 > the expanded prefix contains slashes and the original string doesn't.
 > Maybe a better solution would be to do nothing in such cases.

Does this apply only to file completion?  What if the expansion happens
in some other context where slashes aren't special?

Re: PATCH: tricky.c (was messages from Andrej and Bart)

[Sven Wischnowsky]

Bart Schaefer wrote:

>  > The problem is that after expansion, the code can't find out
>  > what came from the expansion in cases like `${foo}x<TAB>'.
> 
> Hrm ... so what was happening in the old completion code in this case?

Thinks went utterly wrong, even worse than what the new code did
before the patch: 

  % echo $PWD:h<TAB>
  % echwischnow/

... of course, the result depends on the last pathname component.

>  > So the patch just uses the expanded prefix if it has the problem that
>  > the expanded prefix contains slashes and the original string doesn't.
>  > Maybe a better solution would be to do nothing in such cases.
> 
> Does this apply only to file completion?  What if the expansion happens
> in some other context where slashes aren't special?

The error occured only in the code that is used when completing
filenames. In other contexts the expanded prefix would be used and
completed.

Bye
 Sven


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