Re: Two more (possible) problems with the new completion...

Re: Two more (possible) problems with the new completion...

[Sven Wischnowsky]

Peter Stephenson wrote:

> 
> Maybe these are just the result of badly applied patches, like the
> last two, but if they are I'll never know without asking...
> 
> 1) The following works (and very useful it is, too: goodbye, cdmatch):
> 
> compctl -W "($cdpath)" -/ cd
> 
> but the following, which as far as I can see should be equivalent
> apart from tracking changes in $cdpath, doesn't:
> 
> compctl -W '$cdpath' -/ cd
> 
> (no matches produced).
> 

`-W' behaves like `-k', you only need `compctl -W cdpath -/ cd'. There 
is some extra hacklet that ensures that the old style (giving one
directory) still works (in most cases): if the string isn't an
parameter name, it is used directly as a directory name. So, unless
you have a directory named `$cdpath' (*not* the value of `cdpath') it
will produce no matches.

> 
> 2) I suppose this is more than a misplaced fixsuffix(); you need
> menucompletion set, though setting automenu and hitting <TAB> twice
> has the same effect:
> 
> compctl -q -S / -k '(foo bar)' echo
>         ^^^^^^^ this is the important bit
> 
> % echo <TAB> -> bar/
>                    ^cursor here, over the slash
> 
> followed by <RET>:
> 
> % echo ba/
> ba/
> 
> so at some point the cursor is being put one character too far back.
> It doesn't happen with a `genuine' autoremoveslash.

This is a real bug (there really is an embarassing number of them,
sigh). The cursor should be moved on the suffix only when completing
inside words (paths, whatever).

Bye
 Sven

*** os/Zle/zle_tricky.c	Thu Nov  5 13:02:37 1998
--- Src/Zle/zle_tricky.c	Thu Nov  5 13:02:45 1998
***************
*** 5068,5074 ****
      if (menuwe && m->ripre && isset(AUTOPARAMKEYS))
  	makeparamsuffix(((m->flags & CMF_PARBR) ? 1 : 0), menuinsc);
  
!     if (menucmp)
  	cs = menuend;
  }
  
--- 5068,5074 ----
      if (menuwe && m->ripre && isset(AUTOPARAMKEYS))
  	makeparamsuffix(((m->flags & CMF_PARBR) ? 1 : 0), menuinsc);
  
!     if (menucmp && !menuwe)
  	cs = menuend;
  }
  


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

PATCH: Re: Two more (possible) problems with the new completion...

[Peter Stephenson]

Sven Wischnowsky wrote:
> `-W' behaves like `-k', you only need `compctl -W cdpath -/ cd'. There 
> is some extra hacklet that ensures that the old style (giving one
> directory) still works (in most cases): if the string isn't an
> parameter name, it is used directly as a directory name. So, unless
> you have a directory named `$cdpath' (*not* the value of `cdpath') it
> will produce no matches.

Fine, but ... :-)

In this case the return value of get_user_var() is a pointer to the
stored array itself, so the array shouldn't be modified.  The present
code does a mischief to the value of $cdpath after the completion is
finished.  The patch below fixes it (I can even do this one myself).


> > so at some point the cursor is being put one character too far back.
> > It doesn't happen with a `genuine' autoremoveslash.
> 
> This is a real bug (there really is an embarassing number of them,
> sigh). The cursor should be moved on the suffix only when completing
> inside words (paths, whatever).

This works fine.  I don't think it's suprising that there are small
bugs left, it was a major change to the most complicated part of the
shell (possibly the most complicated part of any shell).

*** Src/Zle/zle_tricky.c.arr	Thu Nov  5 13:16:46 1998
--- Src/Zle/zle_tricky.c	Thu Nov  5 13:31:47 1998
***************
*** 3854,3872 ****
  		addwhat = CC_FILES;
  
  		if (cc->withd) {
! 		    char **pp, *tp;
  		    int tl = strlen(ppre) + 2, pl;
  
! 		    if ((dirs = pp = get_user_var(cc->withd))) {
  			while (*pp) {
  			    pl = strlen(*pp);
  			    tp = (char *) halloc(strlen(*pp) + tl);
  			    strcpy(tp, *pp);
  			    tp[pl] = '/';
  			    strcpy(tp + pl + 1, ppre);
! 			    *pp = tp;
  			    pp++;
  			}
  		    }
  		}
  		if (!dirs) {
--- 3854,3875 ----
  		addwhat = CC_FILES;
  
  		if (cc->withd) {
! 		    char **pp, **npp, *tp;
  		    int tl = strlen(ppre) + 2, pl;
  
! 		    if ((pp = get_user_var(cc->withd))) {
! 			dirs = npp =
! 			    (char*) halloc(sizeof(char *)*(arrlen(pp)+1));
  			while (*pp) {
  			    pl = strlen(*pp);
  			    tp = (char *) halloc(strlen(*pp) + tl);
  			    strcpy(tp, *pp);
  			    tp[pl] = '/';
  			    strcpy(tp + pl + 1, ppre);
! 			    *npp++ = tp;
  			    pp++;
  			}
+ 			*npp = '\0';
  		    }
  		}
  		if (!dirs) {

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

Re: PATCH: Re: Two more (possible) problems with the new completion...

[Peter Stephenson]

Peter Stephenson wrote:
> The patch below fixes it (I can even do this one myself).
>
> ! 			dirs = npp =
> ! 			    (char*) halloc(sizeof(char *)*(arrlen(pp)+1));

aaaarggh... except that should be a (char**) in front of halloc(), I
missed it amongst all gcc's other warnings.

*** Src/Zle/zle_tricky.c.arr	Thu Nov  5 13:16:46 1998
--- Src/Zle/zle_tricky.c	Thu Nov  5 13:53:41 1998
***************
*** 3854,3872 ****
  		addwhat = CC_FILES;
  
  		if (cc->withd) {
! 		    char **pp, *tp;
  		    int tl = strlen(ppre) + 2, pl;
  
! 		    if ((dirs = pp = get_user_var(cc->withd))) {
  			while (*pp) {
  			    pl = strlen(*pp);
  			    tp = (char *) halloc(strlen(*pp) + tl);
  			    strcpy(tp, *pp);
  			    tp[pl] = '/';
  			    strcpy(tp + pl + 1, ppre);
! 			    *pp = tp;
  			    pp++;
  			}
  		    }
  		}
  		if (!dirs) {
--- 3854,3875 ----
  		addwhat = CC_FILES;
  
  		if (cc->withd) {
! 		    char **pp, **npp, *tp;
  		    int tl = strlen(ppre) + 2, pl;
  
! 		    if ((pp = get_user_var(cc->withd))) {
! 			dirs = npp =
! 			    (char**) halloc(sizeof(char *)*(arrlen(pp)+1));
  			while (*pp) {
  			    pl = strlen(*pp);
  			    tp = (char *) halloc(strlen(*pp) + tl);
  			    strcpy(tp, *pp);
  			    tp[pl] = '/';
  			    strcpy(tp + pl + 1, ppre);
! 			    *npp++ = tp;
  			    pp++;
  			}
+ 			*npp = '\0';
  		    }
  		}
  		if (!dirs) {


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

Re: PATCH: Re: Two more (possible) problems with the new completion...

[Sven Wischnowsky]

Peter Stephenson wrote:

> 
> Sven Wischnowsky wrote:
> > `-W' behaves like `-k', you only need `compctl -W cdpath -/ cd'. There 
> > is some extra hacklet that ensures that the old style (giving one
> > directory) still works (in most cases): if the string isn't an
> > parameter name, it is used directly as a directory name. So, unless
> > you have a directory named `$cdpath' (*not* the value of `cdpath') it
> > will produce no matches.
> 
> Fine, but ... :-)
> 
> In this case the return value of get_user_var() is a pointer to the
> stored array itself, so the array shouldn't be modified.  The present
> code does a mischief to the value of $cdpath after the completion is
> finished.  The patch below fixes it (I can even do this one myself).

Thanks. The patch below goes on top of this, just to keep gcc quiet.

BTW, in the Peter's glob patch he added some braces to keep gcc from
emitting lots of `ambiguous else' warnings and I've similiar things in 
zle_tricky.c. We should remember to fix all of these (and the `char
used as subscript' warnings) before the next official release.
all th

Bye
 Sven

*** os/Zle/zle_tricky.c	Thu Nov  5 14:17:03 1998
--- Src/Zle/zle_tricky.c	Thu Nov  5 14:17:08 1998
***************
*** 3848,3854 ****
  
  		    if ((pp = get_user_var(cc->withd))) {
  			dirs = npp =
! 			    (char*) halloc(sizeof(char *)*(arrlen(pp)+1));
  			while (*pp) {
  			    pl = strlen(*pp);
  			    tp = (char *) halloc(strlen(*pp) + tl);
--- 3848,3854 ----
  
  		    if ((pp = get_user_var(cc->withd))) {
  			dirs = npp =
! 			    (char**) halloc(sizeof(char *)*(arrlen(pp)+1));
  			while (*pp) {
  			    pl = strlen(*pp);
  			    tp = (char *) halloc(strlen(*pp) + tl);


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