From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10624 invoked from network); 21 Mar 2001 09:59:05 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 21 Mar 2001 09:59:05 -0000 Received: (qmail 23483 invoked by alias); 21 Mar 2001 09:58:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13683 Received: (qmail 23469 invoked from network); 21 Mar 2001 09:58:55 -0000 From: "Bart Schaefer" Message-Id: <1010321095840.ZM16967@candle.brasslantern.com> Date: Wed, 21 Mar 2001 09:58:40 +0000 In-Reply-To: <3AB7CC59.E566C8A1@u.genie.co.uk> Comments: In reply to Oliver Kiddle "Re: Moving completion functions" (Mar 20, 9:32pm) References: <3AB7CC59.E566C8A1@u.genie.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Zsh workers Subject: Re: Moving completion functions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 20, 9:32pm, Oliver Kiddle wrote: } Subject: Re: Moving completion functions } } Bart wrote: } } > What exactly would you like fpath to contain by default? Nothing? } } Yes. Unless the parent process exported FPATH to zsh. Long, long ago it was decided that it was a bad idea to import FPATH. So long ago that it's not in the zsh-workers archive, unfortunately. Probably has something to do with the fact that its a huge security hole, i.e., you can cause some other user's shell to inherit a trojan via any function you can guess he might autoload. } > it also sets it to get the stuff from the Functions subdirectory, etc. } } I always thought of them as just examples and user contributions as } opposed to being part of zsh's functionality. Before the new } completion, they had to be manually installed and added to $fpath. I've } just noticed though that they are now mentioned in the documentation } which I suppose makes them more official. Not all of them are mentioned in the docs, and some of them really are not much more than examples; I think we should rearrange some of the files under Functions/ while we're doing the ones for Completion/. (I will try to make some suggestions after I've had some sleep.) } > If we remove the Completion directories from the default fpath, then we } > must also give up --enable-function-subdirs. Not that we can't use the } > subdirs for installation, but that we must hardwire the installation so } > that compinit can know what to add to fpath. Even then, compinit needs } > to get the base path (to which to append /Completion/...) from } > somewhere. } } As I said with the original suggestion, there could be a variable set } to point to the base of the installed functions. A parameter set how? By hardwiring it at compile time? I suppose that the zsh/complete module could define one. } I don't understand why compinit would need to know before-hand what } directories it should add - it would just use a bit of globbing } modified for $OSTYPE and options passed to it Maybe; I'm not convinced. } Do we need to account for kshautoload though? The patch I included for compinit, did so, for compinit itself; but: } How does someone with kshautoload set get the new completion system to } work short of doing unsetopt kshautoload? The only way is to "zcompile -z" the whole thing and then put the .zwc file in fpath. This has been mentioned before (it may even be in the docs somewhere). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net