Re: Moving completion functions

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

First, I've got some comments relating to specific functions:

> Functions/Misc/acx		Functions/Examples	# Misc?
> Functions/Misc/cx		Functions/Examples	# Misc?

I'd delete these because they would be better written as aliases. They
could always be added to the example startup files.

> Functions/Misc/multicomp	Functions/Compctl

Is this one still relevant now that we have matching control.

> Functions/Misc/promptnl		Functions/Misc

This is new right? Was this something to do with evading the promptcr
problem?

> Functions/Misc/run-help		Functions/Misc	# Add #autoload line?

On the basis that functions starting #autoload are autoloaded by
compinit, and that #autoload was intended for functions which are part
of the completion system, should we be using #autoload in
non-completion system related functions. I'm not sure that I'd want
this autoloaded anyway because I don't use it.

> Functions/Misc/zless		Functions/Misc

I'd delete this one too because of the LESSPIPE feature in recent
versions of less. It could always be found a good home on the web
pages. If it stays, I'd put it in Examples.

> Functions/Misc/zls		Functions/Misc

This I'd definitely put in Examples. I can't believe anyone would use
it instead of their binary ls but it is a nice example for the stat
module.

Bart wrote:
> I've
> left in Functions/Misc anything that it seemed likely one might want to
> have in one's "standard" fpath, relocated stuff related to old compctl
> completions into Functions/Compctl, and stashed everything else in
> Functions/Examples.  A few of those latter might possibly want to be
> in Misc instead; I've marked those.

I agree with the Compctl division although it might be better to put
them in the compctl-examples file to get them out of the way.

For the rest it isn't very easy. The only ones which I can't see anyone
possibly wanting in their $fpath are zls and randline. pushd is
basically there for backward compatibility which would make a good
category if there were more. I would class acx, cx, harden, proto, yp,
yu, checkmail, mere, zed and zmv as useful functions which many people
might want to use. Most of the rest (zkbd, is-at-least, nslookup,
zstyle+, run-help, colors and zrecompile) are the ones which are almost
an integral part of zsh in that other things rely on them and they are
mentioned in the documentation.

This might suggest some sort of Example/Contrib/Zsh division although
that isn't want I originally meant to suggest. Maybe we could not
install the examples, have a configure option to install the user
contributions and always install the other things.

The other thing which might be worth doing is looking through any other
functions any of us have. From these we may find some suitable for the
distribution and others which can go under the user contributions on
the web pages.

I've attached two of mine: hgrep is like grep but highlights
matches. showargs lists arguments one per line which can be handy when
trying to work out what is going on with some quoting. Do you think
either of these may be suitable?

I also have these:
  freload() { while (( $# )); do; unfunction $1; autoload -U $1; shift; done }
  dr() { ls -lFbd ${@:-*}(/) }
  lx() { ls -lFbd ${@:-*}(x^/) }

The example startup files are another thing we should look at before
4.0. I'd be in favour of modifying them to use new-style completion and
having some typical example zstyles and generally to be a bit more
up-to-date. If there is agreement on this, I'll come up with a
suggested patch for them.

Finally, there was a mention at some point about changing the letters
of some compadd options as we were originally constrained by
consistency with compgen which had many of the old compctl options. Was
this ever done or looked in to? I suppose we still have compctl but
some could be better like -J and -V.

Oliver