From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9011 invoked from network); 20 Aug 1998 11:24:12 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 20 Aug 1998 11:24:12 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id HAA27942; Thu, 20 Aug 1998 07:14:40 -0400 (EDT) Resent-Date: Thu, 20 Aug 1998 07:14:40 -0400 (EDT) Date: Thu, 20 Aug 1998 13:17:01 +0200 (MET DST) Message-Id: <199808201117.NAA24440@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: Bruce Stephens's message of 20 Aug 1998 11:48:13 +0100 Subject: Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand) Resent-Message-ID: <"uYpF-2.0.Xq6.WK0tr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4339 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bruce Stephens wrote: > > ... > > > Since I wouldn't like to mess with the shell lexer/parser just to > > add a new syntax for completion control, I would (as a first step) > > implement it as a new builtin that gets some filenames arguments (or > > read stdin), reads these files and expects the new syntax there. > > I think there's potential for confusion. If completions use > functions, I'd want to put the function definitions in the same file > as the completion. Similarly, I might want to define an array in the > same file, too. There might be a case for having files which define > functions together with completions for them. > Yes, I was aware of that problem. If the completion control command would read stdin we could put it into the normal setup files with the definitions in here-documents (which is a bit ugly). Also we could allow the definition of array/variables and functions in the definition files (at least I think, we could do that). > ... > > An extra feature I'd like to see (which may be in your suggestion, but > I missed it if so) is sharing of components. Most commands have > basically the same structure: a set of options (with - or --) with > arguments, and then an optional list of files. Quite a few commands > share a number of options, but not all of them. > There are two ways to do that: with some compctl stuff or with some kind of `alias' in the command that interprets the definition files. The second one doesn't look too hard and the first one is possible with my last changes, more exactly the fixes to the `-l' flag. With that, one can do: compctl ... __common_options compctl ... -l __common_options ... foo to `include' the flags from `__common_options' into the definition for the command `foo' (in fact, this was the reason why I gave the `-l' flag an optional argument, unfortunately this never quite worked until now). > > ... > > Maybe it would be useful to have special support for cvs-like commands > too, where cvs takes some options, and a subcommand, and each > subcommand has its own set of options and arguments, many shared. But > maybe not: there probably aren't enough commands like that for it to > be worthwhile. This too should be easy enough with a combination of `-x' and the `-l' stuff mentioned above. Of course, this could be one of the things for which some kind of short-cut notation may be interesting. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de