Re: PATCH: completion cleanup

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> On Nov 1,  8:50am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: completion cleanup
> }
> } Ohhh, noooo!
> } 
> } I sent the wrong uu-file. I'm so sorry. And ashamed. Ahem.
> 
> The wrong diff (8475) contained a hunk to have compinit call zmodload on
> the parameter and zleparameter modules.  This latest one (8478) does not
> include that hunk.  Is it needed or not?

It is not needed since 8440 made them be autoloaded.

However, after adding the `funcstack' parameter, I made the parameter
module be loaded in `compinit' because I wanted to make sure that this 
parameter is always correct (if the module is loaded when there are
already functions currently being executed, these functions will be
missing from `funcstack').

So, Felix Rosencrantz wrote:

> I started pulling zsh from Tanaka's CVS repository, and was seeing a few
> undefined functions due to the separation of all the completion code.
> So I started compiling without dynamic loading support, to find these
> problems at link time rather than run time.

I hope 8490 already fixed these...

> Once I got a good build, I found that the compinit function fails
> because it calls "zmodload -i parameter".  Zsh reports "bad option:-i".
> In builtin.c, there is an #ifdef that controls what command line options
> are valid for zmodload depending on whether or not dynamic loading is
> enabled.

Ouch, hadn't thought of that.

> What is the proper solution to this problem?
> 
> Should compinit (and any other functions) be changed to check if it
> is in a dynamic loading situation before calling zmodload?  Or should
> zmodload be modified to ignore "-i" (and other flags) in non-dyanmic
> loading situations?

I think the static linked version of `zmodload' should be quiet (and
do nothing) if the module we attempt to load is linked in and should
barf otherwise.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de