From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15803 invoked from network); 2 Feb 2000 14:21:34 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Feb 2000 14:21:34 -0000 Received: (qmail 26656 invoked by alias); 2 Feb 2000 14:21:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9529 Received: (qmail 26648 invoked from network); 2 Feb 2000 14:21:19 -0000 Date: Wed, 2 Feb 2000 15:21:17 +0100 (MET) Message-Id: <200002021421.PAA11232@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Alexandre Duret-Lutz's message of 28 Jan 2000 17:24:14 +0100 Subject: _call (was: Re: PATCH: _diff (new), _prcs (upgrade)) Alexandre Duret-Lutz wrote: > Sven> The only problem is that this means that such options will always be > Sven> combined with the ones a user might define in a style. I.e. there are > Sven> actually two types of options a completion function might give to a > Sven> command: those that *have* to be there to make it work in the way the > Sven> function needs it (like the -v for diff) and those the completion > Sven> functions *suggests* to use -- which may be overridden by a user's > Sven> style. Ideally, we should support both cases... > > Yes, I was speaking of what you call *suggested* options. As for now, to > set these options, we should set a default style in compinit or elsewhere. > But since these *suggested* options must be quite uncommon, this is not a > problem. ok. I was about to start writing _call when I was brought to a halt, because, thinking again and looking at some of our functions, I'm not so sure about the two different kinds of arguments/options any more. Maybe we should only think about `ways to get certain informations' instead of `parameterizing commands'. My suggestion already allowed to give other commands with styles but if someone really configures a completely different command the options supplied by the calling function may be completely senseless. So, maybe we should just make _call get the suggested command line and let users override them completely or leave them alone. I would then make _call take a tag as its first argument which is used to look up the style `command' (somehow I think this is cleaner than using a standard tag and different style names). Maybe we should even make _call concatenate these arguments (or the strings it gets from the style) and eval the whole thing so that users can define pipelines to be executed. E.g., in _pids we would use `_call pids command ps' and `_call display command ps' (or maybe without the `command'). In _diff_options we would use `_call diff-version diff -v' and so on. The only problem is that -- in cases like the _diff -- the users would have to know what the command has to do, but as long as we keep tags and styles documented... And it looks much cleaner to me than the auto-option and auto-command magic we were discussing before. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de