From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25212 invoked from network); 12 Mar 2000 00:30:07 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 12 Mar 2000 00:30:07 -0000 Received: (qmail 2241 invoked by alias); 12 Mar 2000 00:30:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10080 Received: (qmail 2184 invoked from network); 12 Mar 2000 00:29:58 -0000 From: "Bart Schaefer" Message-Id: <1000311234601.ZM26677@candle.brasslantern.com> Date: Sat, 11 Mar 2000 23:46:01 +0000 In-Reply-To: <38CABABC.4601EB4E@u.genie.co.uk> Comments: In reply to Oliver Kiddle "Default fpath" (Mar 11, 9:29pm) References: <38CABABC.4601EB4E@u.genie.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Zsh workers Subject: Re: Default fpath MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 11, 9:29pm, Oliver Kiddle wrote: } Subject: Default fpath } } 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. I'm also back to the problem that I install into /usr/local/stow/zsh/ and then use the "stow" package to symlink into /usr/local/ -- but the compiled-in fpath still references /usr/local/stow/zsh/share/zsh. I'd fixed this at one point but it seems to have reverted. (Same for the module_path.) } 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 } [...] } } 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. This gives me an idea ... it ought to be possible to point autoload (or some new builtin) at a zcompiled digest file and have it mark all the functions therein for autoloading. That way, you could (once) select the functions to compile into the digest, then simply add the digest to your $fpath and issue a single autoload command. (Note 1) The digest-file equivalent of `autoload $dir/*(.)`, you see. I suppose you can do `autoload ${$(zcompile -t file.zwc):t}` but that requires an extra process, and it doesn't cover cases where one component file of the .zwc contained multiple function definitions. Meanwhile, I use something like this: typeset -U fpath zfpath zfpath=( ... ) # Personal function dirs here autoload $^zfpath/*(N.:t) # Aliases OK in my own funcs (( $#fpath )) && autoload -U compinit fpath[(r)*site-func*]=( $zfpath ) It's actually more complicated than that because I'm in the middle of inventing some code to set zfpath in a $ZSH_VERSION-specific way, so I can shuffle out some old functions that aren't needed anymore. I don't put anything in site-functions, ever; hence re-slicing it with $zfpath. Hmm, just noticed that if site-functions doesn't appear in $fpath, but it's otherwise non-empty, that's going to add $zfpath to the end, not somewhere near the beginning. Have to think about that; I don't have any overrides for the default set of functions *now* ... } 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 That's an argument for making the location a configure-time option, at least, with one option being to leave it out entirely. What harm does it do, though, to have a directory in $fpath that contains no files? } and others like me subdivide it into various subdirectories but don't } put any functions directly in it. There's certainly not going to be a compile-time fix for that -- nor a way to get compinit to deal with it properly AFAICT. So you're still going to have to autoload the functions from those directories yourself. } 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. We need to clean up Misc/ anyway; the compctl-related functions should be called out as such, not lumped in with other utilities, so that they can be avoided now and more easily obsoleted in the future. } 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. ^^^^ "They" being the directories that contain completion functions. I submit that this mistake can't survive very long, because users won't be able to run compinit if they've removed its directory from $fpath. It's the sort of mistake you make exactly once. } Similarly, promptinit would add the Prompts directory to $fpath. But then you're enforcing --enable-function-subdirs behavior, aren't you? Further, if compinit added directories to $fpath, how does the user specify in what order those directories are added? I might not want my local directories to come before the zsh system ones; e.g. with 3.0.x, I only want my local copy of `multicomp' found when the one that came with zsh isn't installed, because mine's rather old and the chances are that the system one works better. (Yes, I should just copy a newer one into my directory. That's not the point.) } 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. That's a reasonable idea, though (other than "functions" and maybe "lib") I can't decide what the standard set of key names should be. I dislike the idea of following the autoconf naming convention; I don't really think bindir, datadir, infodir, etc. are especially useful. Backing up again: } 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? It's a function so that it can use setopt localoptions, create local variables, and use "autoload -U" to avoid alias expansions. That last is probably the most important. There's a lengthy discussion of this from June 1999 in the archives; most messages in the thread have the subject Re: PATCH: Re: Completion and global aliases and the patch that resulted is article 6857. Of course, we could add a "source -U ..." or some such to stop aliasing even in sourced files, but as source has never accepted options before I find that slightly distasteful. Note 1 -- While we're on the topic of zcompile, it could use: (1) a way to append to an existing .zwc, rather like `ar' works, and (2) an option to say whether each function should be autoloaded zsh-style or ksh-style, so that the right thing happens regardless of the run- time setting of kshautoload.) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com