From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17362 invoked from network); 24 Jul 2000 08:53:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Jul 2000 08:53:13 -0000 Received: (qmail 15339 invoked by alias); 24 Jul 2000 08:53:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12350 Received: (qmail 15332 invoked from network); 24 Jul 2000 08:53:00 -0000 Date: Mon, 24 Jul 2000 10:52:58 +0200 (MET DST) Message-Id: <200007240852.KAA05409@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Fri, 21 Jul 2000 15:22:33 -0700 Subject: Re: _arguments parsing of --help output Bart Schaefer wrote: > Many GNU commands include short options in the --help output as well as long > ones; e.g. `tar --help' emits lines like "-m, --modifcation-time ...". The > code in _arguments accounts for this by splitting the line at commas, but > then discards the short form of the option. > > Is there a reason that we don't attempt to complete the short forms as well? The only problem I can see is if the user-supplied specs contain those options, too. Currently _arguments does not discard additional definitions but the first one takes precedence with respect to argument handling (arguments of options): _arguments '-e:ea:(1 2)' -e -b -p This will make `foo -e ' complete `1' and `2' but `foo -' lists both (with auto-descriptions). Hm, maybe we should do something about that. The code in _arguments takes care that the user-supplied specs are preferred over the automatically derived ones, though. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de