From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19299 invoked from network); 11 Oct 2006 16:53:55 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.6 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 11 Oct 2006 16:53:55 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 75056 invoked from network); 11 Oct 2006 16:53:46 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 Oct 2006 16:53:46 -0000 Received: (qmail 8923 invoked by alias); 11 Oct 2006 16:53:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22866 Received: (qmail 8914 invoked from network); 11 Oct 2006 16:53:43 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 11 Oct 2006 16:53:43 -0000 Received: (qmail 74805 invoked from network); 11 Oct 2006 16:53:43 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 11 Oct 2006 16:53:41 -0000 Received: from exchange03.csr.com (uuk202166.uk.customer.alter.net [62.189.241.194] (may be forged)) by rly19c.srv.mailcontrol.com (MailControl) with ESMTP id k9BGrL6c008184 for ; Wed, 11 Oct 2006 17:53:23 +0100 Received: from cameurexb01.EUROPE.ROOT.PRI ([10.100.137.61]) by exchange03.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Oct 2006 17:30:32 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 17:30:32 +0100 Date: Wed, 11 Oct 2006 17:30:32 +0100 From: Peter Stephenson To: zsh Subject: Re: Please add pinfo completion Message-Id: <20061011173032.f7556e25.pws@csr.com> In-Reply-To: <200610111943.43143.arvidjaar@newmail.ru> References: <20061007013551.GE8188@prunille.vinc17.org> <200610110648.45199.arvidjaar@newmail.ru> <200610110933.k9B9XJTB021853@news01.csr.com> <200610111943.43143.arvidjaar@newmail.ru> Organization: Cambridge Silicon Radio X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.8.20; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2006 16:30:32.0044 (UTC) FILETIME=[9212BAC0:01C6ED52] X-Scanned-By: MailControl A-07-04-02 (www.mailcontrol.com) on 10.67.0.129 Andrey Borzenkov wrote: > Was it intentionally sent to me personally and not to list? No, I've been doing that ever since the default changed about ten years ago. > OK so we now have two possiblities > > - - nice localized output but without any possibility to give specific > options' argument(s) completion > > - - unlimited freedom in completing options limited to hardcoded english > descriptions. > > Now when you are probably the only person understanding how _argument > works - > any chances to merge the above? I.e. extra option to _arguments (something > like _agruments -h help_option, where help_option is variable) to request > description for options? This does not need all this hairy processing or > recognizing of *=FILE or like - just fetch options with help text and use it > instead of supplied one if found. This gives l10n for large part of commands > for free. This requires two bits, a system of supplying descriptions indicating the text is localizable and providing an index and a system for storing and retrieving those localized descriptions. I think this needs to be done as low as possible in the completion system so that as many features as possible, not just _arguments, can benefit. This means wherever the explanation string to be passed to compadd is modified. In particular _describe has a lot to do with it, though how much I don't know; it's probably the place to start. Probably the first thing to do, however, would be to add a localization function system under Functions to retrieve data based on keywords. It can then be inserted gradually into the completion system at any appropriate level. We need to decide: - Where to store data. The path should be configurable from the shell. Files will presumably correspond to languages and I guess the usual system of ru, ru_RU, ru_RU.UTF-8 etc. will work, though I don't know the details of how it's searched. Someone may be able to provide a suitable algorithm for turning LC_ALL/LC_MESSAGE/LANG into a directory name. We'd want to be able to configure the top of the path before locale-specific bit so that we can use the information in the source tree rather than installation, for example. They'd be in the same format and just installed by tarring the directories, though we'd probably want to do it module by module in the same way Functions currently is in config.modules. - What format the data is in. This should make access from shell code easy. The simplest possibility is a file containing definitions of associative arrays, where the keys are as discussed below. Then it's simply a question of sourcing the file. However, that could produce huge memory usage so we may want to be cleverer. We could add additional paths to get to the file, for example. - How to access the data. This is simpler. It's probably going to be a function that sets REPLY. It can do the locale investigation itself, although we may want to cache the result, e.g. if the locale is ru_RU.UTF-8 work out a path to the top of the file tree once and keep it until the locale changes. - The syntax for keys. If we're clever we can use this to simplify the data access problem. For example, a format like "" gives - a reasonably specific format that isn't going to be confused with other descriptions. I deliberately avoided colons because they're already overloaded in the completion system. - the path to a file /comp/cmd/mount.zmsg that could be sourced to give local completions - the name of a key mount-point for the hash in that file that contains the appropriate string to be retrieved. This can probably be retrieved to ensure the maximum re-use, e.g. we keep the same hash in memory while the path after the first % doesn't change and return the requested element. This would work neatly in a case like this where the localization file is associated with the particular contextual completion. Further discussion is invited. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php