From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18254 invoked from network); 31 Jul 2003 15:24:11 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 31 Jul 2003 15:24:11 -0000 Received: (qmail 13381 invoked by alias); 31 Jul 2003 15:24:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18915 Received: (qmail 13370 invoked from network); 31 Jul 2003 15:24:05 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 31 Jul 2003 15:24:05 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [193.109.254.211] by sunsite.dk (MessageWall 1.0.8) with SMTP; 31 Jul 2003 15:24:4 -0000 X-VirusChecked: Checked X-Env-Sender: okiddle@yahoo.co.uk X-Msg-Ref: server-23.tower-36.messagelabs.com!1059665423!99486 X-StarScan-Version: 5.0.7; banners=-,-,- Received: (qmail 2161 invoked from network); 31 Jul 2003 15:30:23 -0000 Received: from iris.logica.co.uk (158.234.9.163) by server-23.tower-36.messagelabs.com with SMTP; 31 Jul 2003 15:30:23 -0000 Received: from gmcs3.local ([158.234.142.61]) by iris.logica.co.uk (8.12.3/8.12.3/Debian -4) with ESMTP id h6VFO13l029355 for ; Thu, 31 Jul 2003 16:24:02 +0100 Received: from gmcs3.local (localhost [127.0.0.1]) by gmcs3.local (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h6VFPVL04313 for ; Thu, 31 Jul 2003 17:25:31 +0200 To: zsh-workers@sunsite.dk (Zsh hackers list) X-VirusChecked: Checked X-StarScan-Version: 5.0.7; banners=.,-,- In-reply-to: <21766.1059044015@csr.com> From: Oliver Kiddle References: <21766.1059044015@csr.com> Subject: Re: Completion function installation Date: Thu, 31 Jul 2003 17:25:31 +0200 Message-ID: <4311.1059665131@gmcs3.local> 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 > now. 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 being better. Oliver