From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18693 invoked from network); 15 Mar 2001 15:47:01 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Mar 2001 15:47:01 -0000 Received: (qmail 27092 invoked by alias); 15 Mar 2001 15:46:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13640 Received: (qmail 27080 invoked from network); 15 Mar 2001 15:46:54 -0000 X-VirusChecked: Checked Sender: kiddleo@cav.logica.co.uk Message-ID: <3AB0E3C3.1EA7A874@u.genie.co.uk> Date: Thu, 15 Mar 2001 15:46:11 +0000 From: Oliver Kiddle X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re: Moving completion functions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sven Wischnowsky wrote: > 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). And, again (or still), some > functions could sensibly be put into different directories. I think it would be better to keep the subdivisions so that they group together things where users will either want all the functions or will want to exclude the whole directory, either by removing the directory from $fpath or by not installing it. For this reason, I think a Network directory is a good idea because it is quite possible to have a computer which is not connected to the network so all the networking related stuff are of no use. The X division is I think useful. Graphic and Sound is a more complex issue because you might care about programs which manipulate sound files or images but not have the ability to play or display them. Another possbile division would be for commands which are related to sysadmin such as those which are only likely to be in root's path. How many functions are we going to have in Unix/Commands? > example, I've put things like _tex, _ps etc. into Unix/Type because That all seems fine. > For some files we could also think about better names, maybe (_vars_eq > comes to mind). Yes, I was going to mention _vars_eq. Maybe _typeset for the name? > Base/_precommand Zsh/Builtin > Builtins/_compdef Zsh/Builtin > # some of these are functions >>From the perspective of a user it doesn't make much difference so it is probably better to keep them together. _precommand is also completing a reserved word and one non-builtin command. Maybe we should put all the builtins in Zsh/Command? > User/_dict Unix/Command I know it isn't related to the function moving but it might be wise to take the _dict_words out of it to make a separate function. _look for example could also use _dict_words. > User/_diff_options Unix/Type Should this maybe go in Unix/Utility? > User/_dirs Unix/Type We use _files -/ in a lot of places in the completion functions. Should we really be calling _dirs instead. I'd be tempted to rename this to _directories because the the abbreviation doesn't achieve much and the name _dirs might be wanted for a completion for the dirs builtin. Actually, we ought to be using this _dirs for dirs because, apart from the -v option, its arguments are directories. > User/_mere Unix/Command I'm not sure this should be in Unix because it is one of the Zsh functions. It could go in Unix/Type though (possibly after a rename) because it is completing a type of files. It might be useful later in an nroff completion or something. > User/_mysql_utils Unix/Command Should this maybe be renamed to just _mysql or _mysql_client? I'm not familiar with mysql so don't really know. > User/_gv Unix/Command > User/_nedit Unix/Command > User/_netscape Unix/Command I think these should go in X/Command because they are all dependant on having X. If they do go in Unix/, then others such as _xv and _xdvi should join them. _imagemagick is okay where it is because some of the imagemagick commands don't require X. > User/_pdf Unix/Command This should be in Unix/Type like _ps. > User/_prompt Zsh/Builtin # hmm... Zsh/Function? If it does go in Zsh/Function then so should _zftp. I think it should stay but this further convinces me that Zsh/Command instead of Zsh/Builtin is a good idea. > User/_use_lo Base/Utility Could this one maybe be renamed? It isn't obvious what the lo stands for. I can't think of any particularly good alternatives (_use--help, _parse_help maybe?) but it should be possible to think of something better. > Peter Stephenson wrote: > > People are going to have to get used to truly huge $fpath's if they > use > > --enable-function-subdirs. > > Yes, unless we want to use Bart's suggestion to remove one level on > installs (personally I prefer to keep it, too -- hmm, maybe giving > users a three-way choice?). My preference would be for the lowest level to be removed leaving directories for AIX, Linux, Zsh etc but not having directories for Type, Command etc. Pruning unwanted stuff out of $fpath can make a big difference to speed when starting zsh on a slow computer, especially when recreating the dump file. Is it only me who uses --enable-function-subdirs? I've always thought it should be the default and possibly only option. It allows a user to be selective about which functions they are getting when zsh has been centrally installed. Oliver _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Control Centre. For further information visit http://www.messagelabs.com/stats.asp