Non-intuitive completion

Non-intuitive completion

[Phil Pennock]

I've not tested this against Peter Stephenson's patched 3.1.5, only
stock release.  And I'm lost as to what's changed in the new stuff.
Also, this isn't necessarily a bug, as it's 'daft' on my part.  But the
results are counter-intuitive, to me at least.

longprompt% zsh-3.1.5 -f
athenaeum% compctl -L print
compctl: no compctl defined for print
athenaeum% print $ZSH_*<TAB>

At which point the leading $ZSH_ is completely ignored and removed, and
the * is expanded out to files in the current directory, as per usual.

Nothing special about the above choice of variable, except that <TAB>
after the Z provides the next three characters.  I'm lazy and wanted
both, so tried '*' to see what zsh would do.  I /know/ it's a filename
glob, but shouldn't the leading text have some effect instead of being
treated as null?

Notably:
athenaeum% print $ZSH_VERSION*<TAB>
beeps whilst
athenaeum% print $ZSH_VERSIO*<TAB>
loses everything before the *.

It looks as though expansion of wibble* doesn't account for wibble being
a 'variable' with null value.  Evidence:
athenaeum% FOO=
athenaeum% print $FOO*<TAB>
produces the file list.  If FOO has a non-null value, it doesn't.

Is this comprehensive enough?
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* r y?

Re: Non-intuitive completion

[Bart Schaefer]

On Dec 1,  2:47am, Phil Pennock wrote:
} Subject: Non-intuitive completion
}
} Also, this isn't necessarily a bug, as it's 'daft' on my part.  But the
} results are counter-intuitive, to me at least.
} 
} athenaeum% print $ZSH_*<TAB>
} 
} At which point the leading $ZSH_ is completely ignored and removed, and
} the * is expanded out to files in the current directory, as per usual.
} 
} Nothing special about the above choice of variable, except that <TAB>
} after the Z provides the next three characters.  I'm lazy and wanted
} both, so tried '*' to see what zsh would do.  I /know/ it's a filename
} glob, but shouldn't the leading text have some effect instead of being
} treated as null?

The default binding for tab is expand-or-complete.

The $ZSH_ is "treated as null" because as soon as you insert the '*' you
aren't doing completion any more, you're doing expansion.  The expansion
of $ZSH_ is empty if $ZSH_ is not set, so it vanishes.

If you don't want to switch on the fly from completion to expansion in
that way, then you have to rebind tab to complete-word.  Try

zsh% bindkey '^I' complete-word
zsh% print $ZSH_*<TAB>

Now it just feeps at you, because a '*' can't appear in a variable name.

Now, if you'd like to see some REALLY strange behavior, which definitely
IS a bug in my book, try

zsh% bindkey '^I' expand-or-complete
zsh% setopt nounset
zsh% print $ZSH_*<TAB>

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

Re: Non-intuitive completion

[Sven Wischnowsky]

Bart Schaefer wrote:

> I notice this patch isn't in pws-11.  Is it made irrelevant by the new
> completion stuff?  If not, can anyone think of a way to test whether
> it's the right thing to do WRT not breaking other uses of zerr() ?

It isn't irrelevant, both normal and new style completion still show
this bug (which is actually caused by the code for expand-or-complete
before the completion code gets to it).

But I still don't know how to find out if it is the right way to do
it. I once had it in one of my versions (of course) and didn't see any 
unexpected behavior but that is certainly far from a complete test.

Bye
 Sven


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

Re: Non-intuitive completion

[Bart Schaefer]

On Dec 3, 12:48pm, Sven Wischnowsky wrote:
} Subject: Re: Non-intuitive completion
}
} Bart Schaefer wrote:
} 
} > ...
} > 
} > Now, if you'd like to see some REALLY strange behavior, which definitely
} > IS a bug in my book, try
} > 
} > zsh% bindkey '^I' expand-or-complete
} > zsh% setopt nounset
} > zsh% print $ZSH_*<TAB>
} 
} The patch below fixes the problem by making zerr() set errflag
} independent of the setting of noerrs. I am far from knowing if this
} should go there (or in paramsubst() or in prefork(), or in...).

I notice this patch isn't in pws-11.  Is it made irrelevant by the new
completion stuff?  If not, can anyone think of a way to test whether
it's the right thing to do WRT not breaking other uses of zerr() ?

Here it is again so you don't have to search the archives:

} *** os/utils.c	Thu Dec  3 09:10:46 1998
} --- Src/utils.c	Thu Dec  3 12:07:49 1998
} ***************
} *** 52,59 ****
}   void
}   zerr(const char *fmt, const char *str, int num)
}   {
} !     if (errflag || noerrs)
}   	return;
}       errflag = 1;
}       trashzle();
}       /*
} --- 52,61 ----
}   void
}   zerr(const char *fmt, const char *str, int num)
}   {
} !     if (errflag || noerrs) {
} ! 	errflag = 1;
}   	return;
} +     }
}       errflag = 1;
}       trashzle();
}       /*

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

Re: Non-intuitive completion

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> Now, if you'd like to see some REALLY strange behavior, which definitely
> IS a bug in my book, try
> 
> zsh% bindkey '^I' expand-or-complete
> zsh% setopt nounset
> zsh% print $ZSH_*<TAB>

The problem is that docomplete() temporarily sets noerrs=1 around the
call to doexpansion(). After some other function calls paramsubst()
finally calls zerr() which does nothing if noerrs is set, i.e. it
doesn't even set errflag which would be correctly handled in
doexpansion().
The patch below fixes the problem by making zerr() set errflag
independent of the setting of noerrs. I am far from knowing if this
should go there (or in paramsubst() or in prefork(), or in...). Of
course setting it at the lowest function in the call chain can have
all kinds of nasty side effects. Maybe someone with more experience in 
zerr() stuff could comment on this (please).

Bye
 Sven

*** os/utils.c	Thu Dec  3 09:10:46 1998
--- Src/utils.c	Thu Dec  3 12:07:49 1998
***************
*** 52,59 ****
  void
  zerr(const char *fmt, const char *str, int num)
  {
!     if (errflag || noerrs)
  	return;
      errflag = 1;
      trashzle();
      /*
--- 52,61 ----
  void
  zerr(const char *fmt, const char *str, int num)
  {
!     if (errflag || noerrs) {
! 	errflag = 1;
  	return;
+     }
      errflag = 1;
      trashzle();
      /*


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