From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21960 invoked from network); 19 Mar 2001 04:38:29 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 19 Mar 2001 04:38:29 -0000 Received: (qmail 8611 invoked by alias); 19 Mar 2001 04:38:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13666 Received: (qmail 8600 invoked from network); 19 Mar 2001 04:38:18 -0000 From: "Bart Schaefer" Message-Id: <1010319043601.ZM13312@candle.brasslantern.com> Date: Mon, 19 Mar 2001 04:36:01 +0000 In-Reply-To: <3AB534CA.AAFF8D96@u.genie.co.uk> Comments: In reply to Oliver Kiddle "Re: Moving completion functions" (Mar 18, 10:20pm) References: <3AB534CA.AAFF8D96@u.genie.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Re: Moving completion functions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 18, 10:20pm, Oliver Kiddle wrote: } Subject: Re: Moving completion functions } } Bart wrote: } > Aliasing is not the only reason for making compinit a function. } } More user's would understand what they are doing when told to source a } file than the autoloading. And, it would avoid the zsh always setting } fpath stuff that I mentioned my dislike for before. What exactly would you like fpath to contain by default? Nothing? The current scheme doesn't set fpath just to get the Completion functions; it also sets it to get the stuff from the Functions subdirectory, etc. 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. Either that, or compinit needs to become a manufactured file, built from a .in that can substitute the necessary fpath from configure. I don't find that a particularly exciting prospect. Issues of setting fpath aside, the following patch makes it possible to source compinit. (Not committed yet, pending further discussion.) One thing that bothers me a bit is that the (ARGC=0) test will give the wrong result if compinit is sourced from within some other function; as far as I can tell, there's no completely reliable way to determine that "source" (or ".") is in progress. Index: Completion/Core/compinit =================================================================== RCS file: /extra/cvsroot/zsh/zsh-3.1/Completion/Core/compinit,v retrieving revision 1.75 diff -c -r1.75 compinit --- Completion/Core/compinit 2001/03/19 02:32:16 1.75 +++ Completion/Core/compinit 2001/03/19 04:13:16 @@ -65,6 +65,8 @@ # queried for whether to use or ignore the insecure directories (which # means compinit should not be called from non-interactive shells). +compinit() { + emulate -L zsh setopt extendedglob @@ -481,3 +483,11 @@ autoload -U compinit compaudit return 0 + +} + +# Find out if this file is being read with "source" or ".", or called as +# an autoloaded function, and re-call as appropriate. + +local -i ARGC # Harmless if sourced, removes readonly if autoloaded. +{ (ARGC=0) 2>/dev/null && [[ -o kshautoload ]] } || compinit "$@" -- 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