Re: Moving completion functions

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

Bart Schaefer wrote:

> 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?

>From the perspective of an installation as opposed to the distribution,
I think the selectively filled $fpath is the key useful purpose of
splitting them up. From the perspective of the distribution the logical
separation of commands into types, utilities and completers etc is
useful.

For this reason, I favour the approach of leaf directories being used
for the logical separation and non-leaf directories being used for
useful installation-specific separations. Then on installation, the
logical separations (leaf directories) are ditched.

> 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.

My main reasons for considering splitting Unix/Command would be for
selective choice of functions but other than our current divisions (X,
Bsd etc), I wouldn't bother unless Unix/Commands contains a lot of
files. It is certainly worth thinking about now while we are doing a
rename though.

> 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.)

This seems like a good idea to me. _combination could possibly have a name that
groups it with _parts_{sep,multi}. I'd not change _all_matches and _dir_list
though because of the readability.

> The script looks good.

Yes, it does. Cheers Sven.

> On a slightly related note, I was wondering whether it's worthwhile to
> create Cygwin/Type/_path_files that includes Andrej's suggestions about
> calling cygdrive, etc.  Then we'd have to make sure that Cygwin
> appeared
> first in $fpath with --enable-function-subdirs, but was installed
> *after*
> Unix without it ... it's also possible that netscape has different
> options
> when executed under cygwin, so we'd need Cygwin/Command/_netscape, etc.

We're going to get many more problems of this sort once we have more
platform specific completions. Linux has it's own lsdev for example
which fortunately doesn't take arguments so the AIX one doesn't get in
its way too much. I wouldn't be suprised if this becomes messy once
IBM finishes it's lvm for Linux if it get's widely adopted for Linux
because my AIX completions will probably half work but have the same
names. I could come up with numerous other examples and have no doubt
that separate directories for the purpose of overloading our namespace
is going to be essential.

This is why my preference remains having no option on installation
(i.e. no options like --enable-function-subdirs) and with functions all
installed into the (non-leaf) directories.

Why have most other people not used --enable-function-subdirs? If it is
because it is quicker to get at the functions with less, vi or whatever
then maybe we should extend equals expansion to expand for autoloaded
functions to their full location in $fpath?

I'm fairly sure that I've said it before but I don't like it that
running zsh, even with -f sets my $fpath to a whole load of things. The
completion functions should be *added* by compinit. To see why I
emphasise added, try the following:
fpath=/whatever zsh
and watch as your .zshrc can't find compinit and has lots of other
errors.

To further explain my reasoning; we install the functions in
/usr/local/share, not /usr/local/lib. This means that we should be
prepared for the functions to be *shared* between different computers,
each of which may run a different operating system. For this reason,
the installation should/could include AIX, Linux, etc directories. But,
supposing we add something like a cgywin _path_files or a Linux _lsdev,
we would want to be sure that we are using the correct one. If the
installation can include Aix, Cygwin etc then we can't rely on
performing this separation during a make install. compinit could check
$OSTYPE and use some intelligence about what it adds to $fpath. In
addition, we could maybe pass compinit options, for example, -x X -i
RedHat if we want to exclude X and include redhat because maybe we used
rpm but didn't use X. promptinit and zfinit would also be responsbile
for their fpath additions.

When I last moaned about $fpath being set, it was probably together
with the why is compinit autoloaded and not sourced question. The most
compelling answer was because of the need for autoload -U to avoid
aliases. We now have the noalias option so compinit could be sourced.
As for the how do we find compinit question, we'd have a variable named
something like $fundir which zsh would automatically set to point to
its location.

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