Re: Handling for ZLE modules

[Zefram <zefram@xxxxxxxxxxxxxxxxx>]

>The other question is how to handle unloading.  One has to be careful
>when bindings remain which point to the function; also, the functions
>are in a linear array like the builtin functions and you may not be
>deleting at the end.  I have arranged it so that the function is
>marked as deleted with name "<deleted>" (which should only be used for
>output), but the table entry is kept.

I don't like this.  Do we retain the binding or not?  If not, we have
to go through every key binding, changing them to undefined-key.  The
alternative would be to maintain link counts for loaded bindings, to
avoid reusing a slot that is bound to some key.

>                             This seems to me a problem to be fixed in
>any script code associated with the (z?)modload -u,

No.  It's a question of the integrity of zsh's internal data
structures, and should be handled by the code itself.

On a related note, we really need to make addbuiltin() and so on handle
failure cases gracefully.  Try loading mod_example.so twice ("modload
./mod_example.so; modload ~+/mod_example.so"): when I tried it it
segmentated.  Modules are going to have to cope with the possibility
that they can't add the builtins, key bindings or whatever that they
want.

And if anyone's counting, I, too, favour the name `zmodload'.

-zefram

(Own up, how many of us are planning how to implement autoloaded modules?)