From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6820 invoked from network); 28 Jan 2000 10:25:33 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Jan 2000 10:25:33 -0000 Received: (qmail 2101 invoked by alias); 28 Jan 2000 10:25:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9455 Received: (qmail 2093 invoked from network); 28 Jan 2000 10:25:27 -0000 Date: Fri, 28 Jan 2000 11:25:22 +0100 (MET) Message-Id: <200001281025.LAA20330@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 10:49:54 +0100 Subject: Re: PATCH: _diff (new), _prcs (upgrade) Alexandre Duret-Lutz wrote: > ... > > I rethought about it this morning, and while I have not changed my idea, I > can describe it differently. My opinion is: we should write $(XXX) if > we are in the completion function for XXX, and $(command XXX) otherwise. > In the former case, we really need to see what the user is actually running, > in order to not complete for the wrong command (that's the case in _diff, > I think); in the later case we need to call a command directly in order > to get unaltered result (case of the call to ps in _pids). But then a hackishly written function may still break everything (if you have a function for diff that actually does something if invoked with zero or only one argument, for example). > Sven> Actually, I wasn't too sure about _pids either... the problem is that > Sven> some users may have functions for ps, diff, and so on that may give > Sven> completely different results when invoked in the way we invoke them. > > Sven> Hm. maybe we should try to solve this in a generic manner by writing a > Sven> function that is called in such cases, like: > > Sven> _call [ ] > > Sven> (i.e. we use `$(_diff ps)', `$(_call ps list)' and so on). > > $(_call diff version)? No, I wasn't clear enough. I meant that any arguments one normally wants to give to the command would come after the : $(_call diff -v was meant for cases where we want to invoke the command more than once, for different purposes (e.g. we call ps to get the pids and to get the lines to display). So the style would only be used to get the command (including: how it should be invoked, i.e. with `command' or not) and any options the user wants to give to it. If the style is not set we use some standard way, so we don't have to set up default styles for this. > ... > > Another point about the $+functions[] test: what if I am writting a > completion function for a shell function? say I need to call it, how do I > do? Good point. Also testing $+commands and $+builtins might help here, but could still be wrong. Hm, I just wanted to make this cleverer but since the style would allow one to override it anyway, we should probably just call it without any pre-command modifier in the default case. Or let _call accept options like -c and -b to say that the default should use `command' or `builtin'. Maybe the should be given with a option, too. So we would have: _call -h pids -c ps -> command ps _call -h list -c ps -> command ps _call diff -- -v < /dev/null -> diff -v (the <... is in the caller) and the user can set zstyle '...:ps-pids' command-line ps -e -o pid zstyle '...:ps-list command-line ps -e -o pid,command zstyle '...:diff' command-line command diff (in the last case _call would stick the -v after the diff) Does this sound sensible? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de