From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20226 invoked from network); 13 Mar 2000 10:42:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Mar 2000 10:42:47 -0000 Received: (qmail 11514 invoked by alias); 13 Mar 2000 10:42:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10110 Received: (qmail 11501 invoked from network); 13 Mar 2000 10:42:39 -0000 Date: Mon, 13 Mar 2000 11:42:38 +0100 (MET) Message-Id: <200003131042.LAA17110@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Oliver Kiddle's message of Sat, 11 Mar 2000 21:29:32 +0000 Subject: Re: Default fpath Oliver Kiddle wrote: > ... > > 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. We plan to cleanup the directories before release anyway -- every suggestion about things will then be welcome, I think. (The Linux/Debian stuff is a bit of a problem anyway, because the files in it are not only useful on linux/debian systems, I think.) Bart Schaefer wrote: > ... > > 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) Nice idea... > ... [ big snip, no strong opinions on that ] > > } 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. Agreed. > ... > > 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 That's a bit problematic because of the little/big-endian thing. I.e. we can't just append to a wordcode file (and I don't want to have multiple headers). But of course we could make it read/change/re-write such files, also allowing deletion of functions. Is it worth it? I mean, creating wordcode files is quite fast for me... > (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.) But currently it is the same as for loading from a normal file, wouldn't it probably be confusing if the wordcode file said how to load it? But don't get me wrong: I never use kshautoload, so I wouldn't be against allowing it. Per-function or per-wordcode file? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de