From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14435 invoked from network); 16 Dec 1998 08:07:42 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 16 Dec 1998 08:07:42 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id DAA00620; Wed, 16 Dec 1998 03:06:41 -0500 (EST) Resent-Date: Wed, 16 Dec 1998 03:06:41 -0500 (EST) Date: Wed, 16 Dec 1998 09:05:05 +0100 (MET) Message-Id: <199812160805.JAA00604@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: "Bart Schaefer"'s message of Tue, 15 Dec 1998 09:05:40 -0800 Subject: Re: wrapper functions in modules Resent-Message-ID: <"iH9bq1.0.a9.HesTs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4812 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bart Schaefer wrote: > > On Dec 15, 1:03pm, Sven Wischnowsky wrote: > } Subject: Re: wrapper functions in modules > } > } Bart Schaefer wrote: > } > Is the new first parameter of doshfunc() needed any longer? > } > } [For those who don't want to look at the code: the argument is the > } name of the function to be executed.] > } > } I added the argument since modules may be interested in it > > Hm. I'm not sure that modules *ought* to be interested in it, but... It's just that wrappers can't get at this information. But I wouldn't resist to remove this or to use a global variable for it. Apropos variables: we could use two static variables for the other arguments a wrapper function gets and which are only passed to runshfunc()... hm, I might produce a patch for this some time. > > One thing a wrapper function might legitimately be interested in is the > context in which it was called. By that I mean, the wrapper might want > to do something different if the function is being run by the completion > widget code (the call to doshfunc() in zle_main.c), the compctl -K code > or -Y code (zle_tricky.c), or the signal traps (signals.c). The signal > handlers can sort of be determined by examination of the name, but that's > not what I'd call the best way to do it (e.g. it's possible to invoke the > trap functions manually without a signal having been received), and that > doesn't work for the other cases. Yes, that would be good to have. Using a global integer variable or an argument and a couple of constants? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de