Re: Added builtins per runtime

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sat, 01 May 2010 23:02:28 +0200
Christoph Kappel <unexist@dorfelite.net> wrote:
> That was exactly my question. Can a module change it's features per runtime? 

I think the interface you want in the C code is probably
handlefeatures() or thereabouts.  You can get similar effects from shell
code with zmodload, for example:


# Load the zsh/stat module, enabling (only) the zstat builtin
% zmodload -F zsh/stat b:zstat
% which zstat
zstat: shell built-in command

# Disable the zstat builtin
% zmodload -F zsh/stat -b:zstat
% which zstat
zstat not found

# Reenable it
% zmodload -F zsh/stat +b:zstat
% which zstat
zstat: shell built-in command


This is under user control, i.e. the zstat builtin is always there to be
enabled from the command line.  If you want to change what builtins or
other feature are actually offered, you need to be a bit more careful.
I *think* you can get away with doing the C equivalent of disabling a
feature, and after that not showing it --- the interface between the
main shell and a module doesn't remember the feature list, it queries
the module every time, so if you present it a different list of features
each time it doesn't care.  However, if a builtin is linked into the
shell, it will be called whatever zmodload sees, which is why I think
you need to ensure you disable the feature before presenting a list with
it missing.

In other words, to disable a builtin (or parameter, math function, or
condition) in a way that doesn't allow the user to reenable it (i) call
handlefeatures() with an appropriate array indicating what you want to
be enabled.  That should probably be an "and" of what is actually
enabled together with zeros for the features you no longer want to
present (ii) next time there's a call from zmodload into your function,
only present the set of features / array of enabled features shortened
so that it doesn't include the feature you want to disappear.  The only
tricky bit is to make quite sure the two arrays are the same length with
the appropriate element missing.  (The point of the interface the way it
is is that the Features array is expected to be invariant while the
array of integers will change each time; your case is atypical.)  I think
that should work, but I have not tried.  If it doesn't work, it's
probably a bug that should be fixed (though I reserve the right to say,
"oh yeah, I never expected it to do *that*" at infuriating points).

I don't think you should be doing this at the level below that of
generic features, the interface isn't as powerful, so even if you're
just interested in builtins, create a list of features with the lists of
feature types other than builtins set to NULL and pass that to handlefeatures().

If you'd like more documentation, please be explicit (though not
necessarily detailed) about where in the documentation it should go and
what it should talk about.  The developer's guide is certainly not for
the faint of heart (and isn't supposed to be), but is capable of
expansion.

Good luck.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/