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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mar 10, 10:49am, Sven Wischnowsky wrote:
} Subject: Re: Problems with the functions[] parameter
}
} Bart Schaefer wrote:
} 
} > I think that wordcode storage of functions has messed up the functions[]
} > assoc from the parameter module.  The value of functions[something] no
} > longer accurately reflects the current state of the function `something'
} 
} Seems to work fine for me both with read and mapped wordcode
} files... could you give me an example?

It's me being silly.  I just figured out that the function I was editing
(to change "autoload -XU" to "autoload -XUt") was being referenced inside
a $(...), so of course the autoload doesn't replace the actual definition
in the parent.

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?)

(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 { ... }.

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?

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