Re: Proof of concept mainstream plugin manager

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 23, 10:03am, Sebastian Gniazdowski wrote:
}
} I occur a problem with traps.

Hm.  The difference between a "real" autolaod and a function that calls
"autoload -X" is a couple levels of function stack depth -- in the "real"
case zsh knows it can optimize out the first call:

torch% functions showfunctrace
torch% autoload !$
autoload showfunctrace
torch% showfunctrace
Src/zsh:30
torch% unfunction showfunctrace
torch% showfunctrace() { autoload -X }
torch% showfunctrace
(eval):1
showfunctrace:0
Src/zsh:33
torch% 

This will affect traps created with the trap command because they
execute in the same scope as the function call that defined them,
rather than "inside" the call that defined them; so some convoluted
trap tricks that rely on the scope may not work.

} This is fixed in 5.1 (occurs in 5.0.8), wonder if
} I can somehow workaround this:

Probably not, it's almost certainly an internal signal handling thing.

There's another problem with the "local FPATH" trick that I thought
of just now:  It changes the load path for all other functions down
the call stack, which is likely to cause some other autoloads to fail.
A better approach is a temporary prepend.

    local FPATH="$ZPLUGIN_HOME/plugins/${ZPLUGIN_CURRENT_USER}--${ZPLUGIN_CURRENT_PLUGIN}:$FPATH"

A less pleasing approach to the whole thing is to use "autoload +X"
instead:

  preload-autoload() {
    FPATH="/tmp:$FPATH" autoload +X $1
  }

This causes the function to be loaded immediately but not run.  So it
"fixes" the trap problem but fills up memory with functions that may
never be used.