Re: Problems with the functions[] parameter (not; but other issues)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 

Interestingly, I just found the same two things, when changing
_diff_options.


> Which leads me to two observations ...
> 
> (1) autoloading the _call function (for example) is inefficient; it is
>     never used except in $(...), which means it is reloaded every time.
>     Would it be useful to use e.g.
> 
>     	#autoload +X
> 
>    at the top of such files?  To mean, "load this as soon as compinit
>    sees it, don't wait for it to be executed via $fpath."  (But what
>    would that mean for compdump?)

Yes, compdump is a problem, nice as it would be. I see only two ways:
make compinit/the-dump-file record the #autoloaded functions with the
options to #autoload in some array/assoc or add a naming convention
for files that are to be loaded immediatly. The first one would
support the nice `#autoload +X' you suggest and the latter would allow 
to get `#compdef' files loaded immediately without having to add an
extra option to compdef. Dunno if that's interesting to have for
#compdef files, though.

> (2) Redirecting stderr of a function is a bit inconsistent with respect
>     to xtrace.  Zsh presently works the same way bash does, which means
>     the xtrace output of shell functions is *not* redirected along with
>     their stderr.  This is not the same as e.g. `do'-loops and { ... }.

What really irritated me here (and it still looks wrong): add

  set -x
  _call version diff -v </dev/null 2>/dev/null
  set +x

to, say, _diff_option, then do `diff <TAB>'. At least I get:

  _diff_options:8 (): _call version diff -v
  _call:3 (): local tmp
  diff - GNU diffutils version 2.7-97r1
  _diff_options:9 (): set +x

Only the `first' line of _call is shown, xtrace output stops when
zstyle is called. Or maybe my exec.c is out-of date, because:

> And (2) in turn leads me to notice a third thing:
> 
> In bash, redirecting the standard error of the `.' command redirects
> the xtrace output from the commands in the sourced file.  This doesn't
> presently happen in zsh, but I think the zsh behavior is more useful;
> other opinions?  Is compatibility more important?  What does ksh do?

if I do `. ./foo 2> bar' I get the xtrace output of the commands in
`foo' in `bar'. Same as for the ksh I have here, btw.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx