From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11034 invoked from network); 24 Apr 2000 05:23:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Apr 2000 05:23:53 -0000 Received: (qmail 18193 invoked by alias); 24 Apr 2000 05:23:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10897 Received: (qmail 18173 invoked from network); 24 Apr 2000 05:23:42 -0000 From: "Bart Schaefer" Message-Id: <1000424052337.ZM30300@candle.brasslantern.com> Date: Mon, 24 Apr 2000 05:23:37 +0000 In-Reply-To: <200004200718.JAA24905@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH: completion for file descriptors" (Apr 20, 9:18am) References: <200004200718.JAA24905@beta.informatik.hu-berlin.de> <38FECB9E.39061965@u.genie.co.uk> In-Reply-To: <38FECB9E.39061965@u.genie.co.uk> Comments: In reply to Oliver Kiddle "Re: PATCH: completion for file descriptors" (Apr 20, 10:19am) X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Completion function directories MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Apr 20, 9:18am, Sven Wischnowsky wrote: } Subject: Re: PATCH: completion for file descriptors } } What I would like is a more logical ordering. I haven't really thought } about this yet, but maybe a Core with some of the functions it } contains now [...] I'd prefer that to be named something other than "Core" ... } a directory with functions like _arguments (not really } generating completions, only helping to add them), one directory with } all those functions that generate a certain type of matches (options, } jobs, pids, file-descriptors, etc.). And then certainly one for the } builtin commands. This sounds OK, too. I also wonder whether we shouldn't move "compinit" and related functions (anything not starting with an underscore, really) up into the Completion directory itself. } The other stuff is harder to decide. _rpm, for example can also be } useful on non-Linux systems. I don't know debian, but I guess the } commands from that directory can be useful elsewhere, too. So maybe we } should package the functions in a way that reflects what the commands } do (network, package-managers, ...). I don't think categorizing them that way is especially useful. For one thing, it means deciding on a list of categories, which is a potentially deep rat-hole. For another, it's no help when deciding which completions to install; if I'm not going to install everything, then I'm probably going to want all of the "networking" completions but only one of the "package manager" completions, etc. I'm not sure that it's even possible to divide things up in a way that helps much with that, but the point is to avoid making arbitrary divisions simply for the sake of dividing. The main things I think we need are (1) to rename the Commands directory (whatever meaning that name once had has long been lost on me) and (2) break the User directory into two directories, one for helpers like _user_at_host and _tilde_files and another for functions that handle commands (which I think ought to be in a directory named Commands, but what do I know). And then if we're going to keep the system-specific directories like AIX and even X, maybe we should subdivide them further into the same two directories that we break User into, and eliminate the system-specific level of hierarchy at install time. So we'd end up with something like Helpers Commands AIX/Helpers AIX/Commands Bsd/Helpers Bsd/Commands etc. etc. (with probably a better name than "helpers"). Things like _diff_options still end up in a fuzzy space, I know ... On Apr 20, 10:19am, Oliver Kiddle wrote: } Subject: Re: PATCH: completion for file descriptors } } I think I would prefer to stick to directories which group together } commands which users will generally have all or none of as it is } easier to specify whether you want a whole directory than to pick } and choose from specific commands taking each on their own. I expect } that it is fairly rare for someone to use rpm on something other than } Linux. That's less true that it would have been even a few months ago -- and even if it's still true, it's silly for _rpm to be the only thing in the Linux directory. Might as well give it back its own, or put it in one named RedHat; after all, almost-but-not-quite everything in the Debian directory is related to the Debian package management system. My general feeling on that specific issue is that we shouldn't worry about it too much -- the packagers of the various linux distributions will pick the completions that are appropriate for their own dists when they build their zsh RPMs or dpkgs or whatever, and their end users will never know or care otherwise (in the main). Any division we make should be either for our benefit as developers or to assist packagers in making the right choices. (Further, note that we -could- use a .distfiles-type mechanism or some such to make the install structure differ from the distribution structure.) Much earlier, Sven wrote: } [...] Andrej comes and says that we should put all the GNU commands } on the side... This brings up a a question of whether we should have helper functions for setting/testing the _is_gnu assoc, like happens now in _make and _diff_options, or to set up the "standard completion environment" like in _main_complete and _complete_help. I thought briefly about doing the latter, but then I noticed this problem: function unfortunate () { setopt NO_localoptions ... } function unsuspecting () { setopt localoptions ... unfortunate } Unsetting localoptions in a nested function has some rather peculiar effects depending on which options change state where. It's not exactly nondeterministic, but it surely can't be determined from the context of the function that unsets localoptions, and probably not from the context of the function that calls that other function. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com