Re: Surprising effect of fun() { local FPATH=...; autoload -X }, and a bug

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 29 September 2016 at 23:50, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Sep 29,  3:58pm, Sebastian Gniazdowski wrote:
> }
> } Turns out a normal fpath-extending loading support is needed for
> } Zplugin, unless a creative solution is found
>
> Your autoload wrapper that sets up the "local FPATH" needs to store
> the FPATH value for each module somewhere, e.g., in a has indexed
> on the module name, and then recall that every time another autoload
> occurs from inside a function that was loaded from that module.

This would lead to aliases? The autoloaded function would have to have
"autoload" calls translated into "zplg_autoload" calls. -U flag causes
problems here. Loading function with aliases disabled.. I could use
$dis_aliases to disable every alias except for "autoload", and this
way in general provide what -U should, however it looks like restoring
$dis_aliases will be difficult after autoload -X, because following
content of autoload stub will not be run

I could also make autoload wrapper continuously active in Zsh session
but that doesn't look nice to me. Having fpath-extending loading
support in place doesn't mean that clean-FPATH goal will not be
reached. Few plugins use autoload -> autoload, so user would have to
load via fpath say 2 times, and 10 times via fpath-clean way. Fair
enough. And even this might not happen, because author of plugin only
has to do all autoloads in plugin.zsh file, not in autoloaded file, to
solve the problem.

> Whether it's possible to find that the name of the module at the
> necessary time, is a harder question.  In 5.3 "whence -v" will
> reliably give you the path from which the function was loaded, but
> it may not in earlier versions.

Supporting starting from 5.3 is fine to me in this case. Good to hear
about whence -v, this should open way to interesting tricks. Side, I
hope there is still some time till 5.3 because I want to make Zconvey
more robust, currently if I press Ctrl-R Ctrl-C continuously, rapidly
then often happens that every 2 seconds I get beep and new line –
zconvey's 2-second scheduled function is being apparently hit. Plan to
get on this with debugger today and to code as you had an idea of how
to make this less probable, will check that. Zconvey can be a cool
plugin, I currently e.g. switch all my sessions to current project
that I work on via "zcm -zz" (zcommodore -z -z, it uses zconvey). Plus
the take-session I mentioned and other possible ideas, I think having
sessions coupled together can get important say among users.

Idea "if you want functionality use latest" is fine to me if it's
about sophisticated functionality. So I exercised idea of extending
5.3 to make further-autoloading work. getfpfunc does:

    pp = fpath;
    for (; *pp; pp++) {

and it's about side-providing additional path to that loop. Had
multiple flawed ideas yesterday but now I'm rather blank. So maybe
actually no idea. Recalling something about if functions do have some
sort of meta-data. Then at some point additional fpath could be
extracted and provided to getfpfunc. Example problem: the state
save-restoration, one more data not serializable via declare -f. Other
flawed idea is autoload option to hold single path. It could store the
path somewhere so that getfpfunc could use it. But sorry I'm currently
not having any actual ideas.

Btw. I've stumbled upon following code in execcmd / exec.c:3054:

    } else if (is_shfunc || type == WC_AUTOFN) {
        Shfunc shf;
        if (is_shfunc)
            shf = (Shfunc)hn;
        else {
            shf = loadautofn(state->prog->shf, 1, 0);

Is this the place where autoload-marked functions are differentiated
from manual-autoload-stub functions?

Best regards,
Sebastian Gniazdowski