Parameters, disable, modules (Re: Self-loading auto-functions)

[Bart Schaefer <schaefer@brasslantern.com>]

On Mon, 25 Oct 1999, Sven Wischnowsky wrote:

> I've fiddled with `parameter.c' a lot over the weekend, adding
> parameters for the `compgen'-replacement. There I made `functions'
> prepend a `<disabled>' prefix to report disabled shell functions (and
> the same string in other parameters).

Waitaminute.  "functions" doesn't output ANYTHING for disabled functions;
it acts as if they don't exist, and you can't get to them via $functions.  
Did you really change that?

Same goes for aliases, etc.

Disable doesn't work very well on functions anyway; all you have to do
is redefine one to re-enable it:

zagzig[27] fnord() { echo foo }
zagzig[28] disable -f fnord
zagzig[29] fnord           
zsh: command not found: fnord
zagzig[30] fnord() { echo foo }
zagzig[31] fnord
foo
zagzig[32] 

Oh, by the way:  autoload +X will happily (re)load the definition for a
disabled function, causing it to become enabled again.  That was not an
intended side-effect, and I rather suspect that both the example above
and this +X side-effect are doing bad things to the hash table internals.

> While I'm at it: does anyone have an idea how we can make the
> parameter module report stuff about zle widgets and keymaps?

Introduce a registry:  A hash table mapping strings with a well-defined
syntax to function pointers with a corresponding call signature.  The zle
module registers its function pointers and the parameters module looks
them up, and vice-versa.  A fallback of some sort is used by each when it
doesn't find the other.

There are some obscure architectures where you can't cast a function
pointer to (void *) and back and so this wouldn't work, but they probably
can't deal with dynamic loading anyway.