From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27500 invoked from network); 15 Mar 2001 17:11:44 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Mar 2001 17:11:44 -0000 Received: (qmail 8584 invoked by alias); 15 Mar 2001 17:11:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13641 Received: (qmail 8572 invoked from network); 15 Mar 2001 17:11:35 -0000 From: "Bart Schaefer" Message-Id: <1010315170428.ZM3855@candle.brasslantern.com> Date: Thu, 15 Mar 2001 17:04:28 +0000 In-Reply-To: <200103150930.KAA23350@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Moving completion functions" (Mar 15, 10:30am) References: <200103150930.KAA23350@beta.informatik.hu-berlin.de> 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 15, 10:30am, Sven Wischnowsky wrote: } } I've used Oliver's suggestion for exchanging the names of the Core and } Base directories and Bart's suggestion to use the singular. I'm still } not too happy with the name `Type', but since we constantly say things } like `type of matches' in the docs, this name is probably not that } bad. The only alternatives I can think of would be "Category" or "Class", but I'm not too excited about those either. } Some directories (esp. Unix/Command) could make one think about } splitting them up even further (Unix/Net, Unix/Graphic, but also } Zsh/Function and probably others). The question to ask is, what's our primary purpose in splitting them up? Is it to allow selective installation? (The original reason for BSD/ and AIX/, I think.) Is it to help us as developers decide where to put new ones? To help users decide what should be in $fpath? To help users and developers understand how the system works? Of course it's some of each of those, but which ones are more important can indicate just how much splitting up is worthwhile. For example, no one would ever selectively install parts of Base/, but it still seems to me important for understanding to subdivide Base/ as you did. On the other hand, the only reason I can see for splitting Unix/Command into more specific directories would be for selective installation, and I'm not sure that's important enough. } The rule of thumb is that those functions were put into Type that are } usable as functions for completing types of , even if they } aren't (yet) used in that way. Seems reasonable to me. } For some files we could also think about better names, maybe (_vars_eq } comes to mind). Yes, that could definitely get renamed as _typeset. I think I'd also rename _set_options and _unset_options as _options_on and _options_off respectively. In a similar vein, consider _labels_all and _labels_next, _matches_all, _parts_multi, _parts_sep, _cache_store, _cache_retrieve, _jobs_bg, _jobs_fg, ... (I have a tendency to want related files to group together in a sorted listing, but in some cases [like _all_matches and _dir_list] I waffle because the readability of the calling scripts will suffer. I also wouldn't use _options_diff because the relationship to _diff is the more important one. Etc.) } Any better way to update the .distfiles[1]? Probably not. The script looks good. -- 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