completion cleanup discussion + patch

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>]

(I hope my comments have kept pace with the changes, I've been editing
furiously as new stuff arrives...)

> I would want to have the
> functions autoloaded -- and for this we need `fpath' (again: this
> could be solved if `autoload foo=<path>' would work).

Not entirely, since currently init searches the autoload directories for
completion definitions.  One possibility is simply for init to assume that
its own directory is where the functions are, and add that to the front of
fpath if it's not there.  If the namespace problem is really bad we can
implement Bart's special _* suggestion, perhaps as a shell option.  I also
quite like the flexibility of the function mechanism for completions.

> Once we renamed `init' and `dump' to `compinit' and `compdump' (what
> Peter probably will do in pws-10 -- at least we already talked about
> it) and if we have only one function for defining them (`compdef'), we 
> have almost reached the state you described.

I was going to say what I was thinking of doing.  The way the files are
sorted into directories may want changing.

init -> compinit
dump -> compdump

Make three directories under Functions/Completion, containing

Core:  stuff the user will need and probably won't want to touch:
compinit, compdump, _files, _path_files, _main_complete, _normal

Base:  stuff the user will probably want, but doesn't need or may want to
edit:  _default, _match_pattern, _match_test, _subscript, _precommand;
maybe some of the more basic functions like _setopt, maybe even _cd, any
offers?

User:  `lucky dip' for everything else.

Probably a README in the top level directory would be a nice touch when
things get settled down.

While I remember: init and dump miscount the number of files which are to
be loaded when there are ones with the same name in different directories,
e.g. if there is a personalised _default as well as a system wide one it
thinks there are two different files to load, whereas only one will be
found.  This isn't as bad as I first though since init and dump count the
same way (though I could have sworn I was getting too many dumps at one
point), but anyway the patch below uses typeset -U and the basename of the
file so it should get the count right (except that . isn't ignored in
fpath).

> Putting everything into
> one function isn't really needed, is it? Especially since dumping
> won't be done that often (but adding a function that calls/sources
> `init', `dump', and `compdef' depending on the options it gets would
> be easy). But then again: this would be an improvement affecting (and
> intersting for) only the the current example.

I'd have thought it would be OK just to have one init file that gets
sourced at the start, and then one command for management (e.g. the
extended compdef).  compdef should probably also let you see how things are
defined, so that the user doesn't need to look at the arrays directly.  I
don't think having compinit as a function is a good idea, even apart from
the typeset's having local effect (I could write a flag not to make the
variable local, now I've neatened bin_typeset() up marginally), since you
only need to run it once and it takes up memory for the whole session.

> > 4. The run-time for completion stuff should _not_ require
> > modification. Even more so, because these functions are very close to
> > winners of Obfuscated Zsh Programming Contest :-)
> 
> You mean the `-M' problem, right? 

I agree the run-time stuff shouldn't *need* modification, but that's
already the case.  It's a slight worry that defining matchers is different
for _path_files, so _match_pattern is probably destined to be slightly
strange, though there are comments on how it should work (I have to admit
I've only vaguely registered what's going on there).

> > This command should behave as function (or be implemented as such). This
> > allows to start with emulate -RL zsh, set all needed options (extendedglob
> > problem :), define any needed local variables without fear to stomp on
> > user's environment. Anything, that this function exports, should 'course be
> > documented.
> 
> The examples need global parameters to keep the state that has to live 
> longer than the execution of the function. If we had parameter
> namespaces, we could cleanly solve this (ksh has them, should we...),
> and we could solve it in a way that will not collide with any
> parameters used by anyone.

(Since then we have underlines in front of comps and patcomps).  I don't
think parameter namespaces would be too hard to implement; just keep
paramtab in another hash table, but I don't have a version of ksh that does
this.  There are actually only four or so variables used (apart from
specials, which are local to completion functions and don't clash with the
use of the same variable outside).

> As to the documentation, if been thinking about this -- the question
> is: where should we document it? Certainly not in the manual, since
> these are only example functions like `zls'.

This is part of a wider problem, which Andrej mentioned, about
installation.  There should at least be an install target for this, though
I suppose people won't want it done with a basic install.  In that case we
need to arrange so that simply sourcing one file will set up all the stuff
that has been installed; maybe a configure option could pick 'core',
'basic' or 'all' to choose how much to install in a single target
directory, then an $fpath check in compinit would do the trick.  Then we
could have a separate manual for the standard function suite which gets
installed with all this stuff

I was thinking about a similar mechanism for the zftp functions, so
similarly I would write one for the zftp function suite and install those
together if requested.  We would definitely need wider feedback from
potential installers to get this right.


--- Functions/Completion/dump.bk	Thu Feb 25 17:23:03 1999
+++ Functions/Completion/dump	Thu Feb 25 17:33:58 1999
@@ -16,7 +16,8 @@
 
 _d_file=${COMPDUMP-${0:h}/init.dump}
 
-_d_files=( ${^~fpath}/_*~*~(N) )
+typeset -U _d_files
+_d_files=( ${^~fpath}/_*~*~(N:t) )
 
 print "#files: $#_d_files" > $_d_file
 
--- Functions/Completion/init.bk	Thu Feb 25 17:23:03 1999
+++ Functions/Completion/init	Thu Feb 25 17:33:56 1999
@@ -211,7 +211,8 @@
   setopt extendedglob
 fi
 
-_i_files=( ${^~fpath}/_*~*~(N) )
+typeset -U _i_files
+_i_files=( ${^~fpath}/_*~*~(N:t) )
 _i_initname=$0
 _i_done=''
 
-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy