Re: completion cleanup discussion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Andrej Borsenkow writes:
 > 
 > The good old completion has some nice features:
 > 
 > 1. It works out-of-the-box. Not setup is needed; immediately after
 > installing zsh users can start with compctl.

One of the things that STILL annoys me about 3.1.2+ is that all the
default compctl settings are gone.  Completion of anything but files
is entirely useless "out of the box."

 > 2. it is easy to modify completion on-the-fly. What is important, it
 > is the same command with the same syntax as used in startup files. It
 > is invariant - 'compctl $(compctl -L cd) cd' is noop as it should be.
 >
 > 3. it is easy to use. It is not a joke. Using compctl amounts simply to
 > listing what is considered a match - no shell programming is needed.

I don't think anyone is proposing removing the simple compctl options.
Even the complex `compctl -x ...` bits will hang around until the new
stuff has been through at least one "official" "production" release,
I expect.

 > What I suggest, is some framework that IMHO makes new completion almost
 > as easy to use as compctl.
 > 
 > 1. use separate array (cpath?) for a completion stuff. Mixing it with
 > fpath is probably a bad idea

I disagree.  However, perhaps the `autoload` commands for the completion
function names could be delayed until nearer the time they're needed.

 > 2. automatically install at least run-time for new completion (and
 > probably the completion for zsh builtins) in standard system-wide
 > location

I've long thought that copying the Functions/ subdir to somewhere in the
configure-selected $(libdir) would be a good idea, regardless of the new
completion code.  I always do so manually when I install zsh myself.

As for enabling default completions, no argument from me; see rant above.

 > 3. provide a single command to make life easier

Given (2), I think it's fine for this to be a shell function rather than a
builtin.  Perhaps the init function needs to go in the "regular" fpath and
all the auxiliary functions into subdirs that aren't added to fpath until
the init function runs.

 > 4. The run-time for completion stuff should _not_ require modification.

This would be ideal, but ... look at Misc/compctl-examples.  There are in
some cases two or three ways to get not-quite-identical completions in
different circumstances.  Further, there are lots of minor differences in
things like completion of command arguments (how many variants of tar,
find, dd and ls are there?) that require tweaking on different platforms
or even different installations of supposedly the same platform.

A better goal should be that the completion run-time should be easy to
modify when necessary -- which was the intent of moving it into shell
functions in the first place.

Sven Wischnowsky writes:
 > > I think, it is time to decide, if we want new style completion be for
 > > wizards only or intended for general user community.
 > 
 > I'd like to think the other way round: use `compctl' if you like it
 > and it is enough for you. If yo don't like it or you have a problem
 > you can't (easily) solve there, use the new completion stuff.
 > 
 > This, btw, is also the reason why I still don't like calling
 > completion widgets from `compctl'.

If I want to use exactly one completion for which there already happens
to be a widget implementation, why should I have to redo all my key
bindings and load other extra functions and dispatch-table arrays just
to get at it?

If we're working out all these complex widget functions, they at least
should be maximally re-usable.

Seriously, although I instigated this whole effort, it remains the case
that 98% of my own completion needs are covered by simple compctls.  If I
want to complete something fancier, say cvs, I use ESC-q to push the
current command line, then run an autoloaded shell function that installs
my set of `compctl -x ...` commands, and then I finish completing when
zle pops the buffer stack at the next prompt.

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

What do ksh parameter namespaces look like, syntactically?

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

Why not in the manual?  The Perl manual has sections that are entirely
dedicated to "template" implementations of various Perl idioms.  If we do
arrange for installation in $(libdir) of the Functions/ directory, there's
no reason not to treat it as a real part of zsh and have a manual section
devoted to it.