From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12090 invoked from network); 8 May 2000 09:00:36 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 May 2000 09:00:36 -0000 Received: (qmail 11598 invoked by alias); 8 May 2000 09:00:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11246 Received: (qmail 11535 invoked from network); 8 May 2000 09:00:19 -0000 Date: Mon, 8 May 2000 11:00:04 +0200 (MET DST) Message-Id: <200005080900.LAA13146@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Zefram's message of Sat, 6 May 2000 09:19:54 +0100 (BST) Subject: Re: PATCH: Re: sudo completion problem Zefram wrote: > ... > > If we can determine that a particular command is processing options in > this way, it would be nice to complet options accordingly. However, > by default options should only be completed before the first non-option > argument. In either case, options should never be completed after a "--". I don't buy this. There *may* be commands or shell functions which take `--' to, e.g., separate different sets of options and arguments. _arguments is intended to be general enough to generate sensible completions even for user-written shell functions, after all. Please lets not make _arguments treat any string from the line special like this. Lets add it to: > I envision _arguments first of all deciding whether the command allows > options everywhere or not. This should be under the control of the > caller, via options to _arguments; possible values are "everywhere", > "only before first argument", "autodetect GNU getopt" (if possible). So wo would have these plus these combined with `and no options after --'. Ok? > _arguments must also check for a "--" argument, and not do option > completion (regardless of option style) if the cursor is after the "--". > All of this then lets it decide whether to complete options or not; > non-option arguments are always a possibility, though we might want to > be clever about handling arguments that start with "-". No patch yet, but adding an option to comparguments (the builtin) for the second (i.e. "only before first argument" the first would still be the default, _arguments could use a different default, I don't care that much about it for now) should be easy. And another option for the "no options after `--'" would be easy, too. But before I start writing it: should the default for _arguments be changed? And would someone be willing to check all uses of _arguments and add the option to the calls that need them? Oh, and does anyone have an idea how to test for GNU-getopts. Reliably? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de