From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24060 invoked from network); 11 Mar 2000 21:29:43 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Mar 2000 21:29:43 -0000 Received: (qmail 13309 invoked by alias); 11 Mar 2000 21:29:37 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10074 Received: (qmail 13298 invoked from network); 11 Mar 2000 21:29:37 -0000 Message-ID: <38CABABC.4601EB4E@u.genie.co.uk> Date: Sat, 11 Mar 2000 21:29:32 +0000 From: Oliver Kiddle X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Zsh workers Subject: Default fpath Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm not convinced that the current situation with respect to zsh setting up the fpath to point to all the directories it installs (plus site-functions) is the best way of doing it. Note that I use --enable-function-subdirs with configure. My .zshrc file contains this: fpath=( $fpath(N) ~/.zfunc $fpath[1]/* ) typeset -U fpath for dir in ~/.zfunc(N) $fpath[1]/* [[ -d $dir ]] && autoload $dir/[^_]*(.N:t) autoload -U allopt zed ... autoload -U compinit compinit -d There's a few things I don't like about having to do it this way. They are more aesthetic than anything else but I still don't like it. I'm not entirely convinced that putting site-functions in the $fpath is a good idea. On many installations, it won't exist, some people might want to put it elsewhere or call it something else and others like me subdivide it into various subdirectories (Apex, Ada, AIX etc) but don't put any functions directly in it. I don't like having to use $fpath[1] - it doesn't seem very clean and I'm relying on it always pointing to site-functions. I realise that I could search for *site-functions in $fpath but I don't think I'd like that any better. The initial fpath contains the Debian and Linux directories despite the fact that I always remove them after installation. I get rid of them with the (N) but I don't think they should be there. I suppose that in the longer term, we'll have to add configure-time checks for these and other operating systems we might have functions for. As a result of $fpath being set to include all the installed function directories, I have to add directories to $fpath, then loop through the same duplicated list of directories to autoload any functions. I can't just loop through all directories in $fpath and autoload everything because I don't want all the zsh supplied functions in Misc. Many people upgrading from older zsh or learning about $fpath anew will assign to $fpath in their .zshrc, clobbering it's current value so I think it is better if they are only added by compinit. The other thing which I've never understood is why compinit (and promptinit) is an autoloaded function: nobody would ever want to run it more than once in a session so why isn't it just sourced? What I think would be a better system is if zsh started with an empty $fpath, compinit was sourced and added any completion function directories to $fpath. Similarly, promptinit would add the Prompts directory to $fpath. The one issue here is that we would need a way to find compinit/promptinit from our setup files. The obvious solution is to have a variable which is set when zsh first runs such as $ZSH_FUNCTIONS. In fact, it might be better in the longer term to have an associative array which points to any compile-time defined directories. So we would have something like: ZSH_INSTALL[functions]=/usr/local/share/zsh/$ZSH_VERSION/functions ZSH_INSTALL[lib]=/usr/local/lib/zsh/3.1.6-dev-19 ZSH_INSTALL[share]=/usr/local/share/zsh etc. Oliver Kiddle