From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12400 invoked from network); 7 Aug 1998 12:33:24 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 7 Aug 1998 12:33:24 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id IAA03728; Fri, 7 Aug 1998 08:11:58 -0400 (EDT) Resent-Date: Fri, 7 Aug 1998 08:11:58 -0400 (EDT) Date: Fri, 7 Aug 1998 14:13:57 +0200 (MET DST) Message-Id: <199808071213.OAA20646@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: Cosmo's message of Fri, 07 Aug 1998 10:28:32 +0100 Subject: Re: ideas: free-search-complete, noexpand Resent-Message-ID: <"ksorX.0.Bw.Dykor"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4285 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Cosmo wrote: > > Sven Wischnowsky wrote: > > > Maybe we should think about developing an easy to read syntax for > > completion control. > > When I looked at compctl to do something simple I scratched my head and thought why > can'tI just specify what the commands usage string is EG > > compctl tar {txruc}[vfbFXhiBelmopw[0-7]] [tapefile] [blocksize] [exclude-file] [- > I include-file] files ... > > Should, with some casting like modification, be able to figure out at least a > sensible default > rule for tar argument completion. > I guess many of us would like to have a real DWIM, but... Doing something like that would require at least some serious parsing and some guessing (what's the difference between include-file, tape-file, and files; and for other commands the same words may have different meanings). Also, some users may prefer to build their compctls according to the way they normaly use the commands (e.g. someone may use only few of the --options of some commands). All in all, I don't think that it is possible to build a parser that turns man-page-synopsises into the correct internal representation. If you meant that the description should be on a somewhat higher level (something like: these options, or these options followed by filenames, than an optional directory-name, then all files), then I would like to agree, but I'm not sure, how easy we can make that (thinking about commands like `find'). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de