Zsh Mailing List Archive
Messages sorted by:
Re: Completion function installation
- X-seq: zsh-workers 18915
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx (Zsh hackers list)
- Subject: Re: Completion function installation
- Date: Thu, 31 Jul 2003 17:25:31 +0200
- In-reply-to: <21766.1059044015@xxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <21766.1059044015@xxxxxxx>
On 24 Jul, Peter wrote:
> At what point do we need to think of a better mechanism for providing
> and installing completion functions? Things which occur to me include
My answer to this is "not yet". I had hoped someone else would have
some thoughts though.
> - people won't mind if the completion function directory is the odd
> megabyte, but won't want it to grow indefinitely with functions they
> never use
> - however, very few people will bother to configure which functions get
> installed even if we provide a more sophisticated mechanism (it can
> already be done by editing config.modules)
> - it's useful to be able to add newly written functions to existing
> installations easily (of course fpath means this is pretty trivial
> for anyone with any shell knowledge)
> - it's useful to be able to find functions for newly installed commands
> which are specialised enough not to have completions supplied with
> the shell.
Not quite sure I understand the last point. Up until now, we haven't
had a limit on how specialised a command should be before we don't
include the function. mysqldiff is perhaps the most obscure at the
moment (it's a Perl script of Adam's).
> All that suggests having something like CPAN for completion functions,
> but that's a lot of work and I doubt we'll get volunteers. Adding
I would have my reservations about a CPAN like system. I'm not too keen
on something which would works outside of existing .deb/.rpm package
systems. I suspect your second point above would be very true.
Few users compile from source so a config.modules tweaking setup would
do little. And, I'm sure the Linux distribution packagers could cut
down the list of functions regardless if they wanted. Where a CPAN like
system could be good is where we have many other optional parts such as
the tcp functions.
One big advantage of the current system is that we don't have to worry
about supporting different zsh versions in completion functions.
bash_completion contains a good few $BASH_VERSION tests. Though it does
perhaps mean that the stable zsh lags behind more than it needs to with
respect to completion functions.
> completions supplied by users is always going to take real work by real
> human beings. I think we have to live with the current mechanism for
Another possbility would be to only include the core stuff with zsh and
try to persuade every other open source package to include the
completion function for themself with themself.
bash_completion is perhaps laying the ground work for this for us with
its /etc/bash_completion.d system. A search on Debian shows only 10
packages with a file in there and half of them are Debian specific. If
it becomes common place for packages to include bash completions, I
doubt they would complain about the addition of a zsh function. /etc is
probably the wrong place for them though, somewhere under $prefix/share
Messages sorted by: