Re: Moving completion functions

[Oliver Kiddle <opk@u.genie.co.uk>]

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