From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10585 invoked from network); 20 Mar 2001 22:36:41 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Mar 2001 22:36:41 -0000 Received: (qmail 24876 invoked by alias); 20 Mar 2001 22:36:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13679 Received: (qmail 24863 invoked from network); 20 Mar 2001 22:36:31 -0000 Sender: opk Message-ID: <3AB7CC59.E566C8A1@u.genie.co.uk> Date: Tue, 20 Mar 2001 21:32:09 +0000 From: Oliver Kiddle X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.18 i586) X-Accept-Language: en MIME-Version: 1.0 To: Zsh workers Subject: Re: Moving completion functions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sven wrote: > Radical idea: let's just wait and do nothing about all this yet. If Probably a good plan. > I don't like _want(|ed)_now, though, because it is too easily confused > with _wanted, I think. And with _wanted we want to add the > completions *now*, too. Fair enough. _wanted_yet would possibly address your second point above but not the first. It would be nice though if we can find some names which better express the difference between _wanted and _requested. I can't though and the current names aren't too bad. > There's now the call to `cvs tag' in it, too. I think using a tag > that looks completely different than the version tags is a good idea > but I otherwise I don't know what to use as a tag. I agree that it shouldn't look like the version tags. I'd try to use something which makes it clear that the tag is set before the move - something like old-comp-dirs or pre-comp-mv. I've never dealt with cvs tags though so am probably not the best person to answer this. > Builtins/_popd Zsh/Command _popd could possibly be something like Zsh/Type/_directory_stack as that is all it completes and it is called by _cd. It might make _cd more readable and would adapt better to changes in popd's usage. The script looks fine though I've not looked in as much detail as before. Other than the naming of _compalso, _wanted, _requested, _next_label, _all_labels and the cvs tag are there any other outstanding issues on this? Bart wrote: > What exactly would you like fpath to contain by default? Nothing? Yes. Unless the parent process exported FPATH to zsh. At the least, we should change zsh so that if FPATH is set in the environment when it starts, the completion directories are added to it instead of replacing it.. > 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. > 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. 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, I'd be very much against any manufacturing of compinit, especially while it is installed below /usr/local/share. > 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. The ARGC test thing is clever. Do we need to account for kshautoload though? How does someone with kshautoload set get the new completion system to work short of doing unsetopt kshautoload? Having tried a few ideas, I can't think of any better ways to detect when source is in progress. Oliver