From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14921 invoked from network); 11 Feb 2009 03:18:29 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 11 Feb 2009 03:18:29 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 11062 invoked from network); 11 Feb 2009 03:18:23 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 Feb 2009 03:18:23 -0000 Received: (qmail 18016 invoked by alias); 11 Feb 2009 03:18:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26548 Received: (qmail 17999 invoked from network); 11 Feb 2009 03:18:16 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 11 Feb 2009 03:18:16 -0000 Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by bifrost.dotsrc.org (Postfix) with ESMTP id 68C7480271F0 for ; Wed, 11 Feb 2009 04:18:12 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KEV00EAOT66Q5Q1@vms173005.mailsrvcs.net> for zsh-workers@sunsite.dk; Tue, 10 Feb 2009 21:18:11 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n1B3I40U007112 for ; Tue, 10 Feb 2009 19:18:05 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n1B3I4lw007111 for zsh-workers@sunsite.dk; Tue, 10 Feb 2009 19:18:04 -0800 From: Bart Schaefer Message-id: <090210191804.ZM7110@torch.brasslantern.com> Date: Tue, 10 Feb 2009 19:18:04 -0800 In-reply-to: <18952.1234307021@pws-pc> Comments: In reply to Peter Stephenson "PATCH: sticky emulation" (Feb 10, 11:03pm) References: <18952.1234307021@pws-pc> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: sticky emulation MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/8977/Tue Feb 10 20:33:54 2009 on bifrost X-Virus-Status: Clean On Feb 10, 11:03pm, Peter Stephenson wrote: } Subject: PATCH: sticky emulation } } This is how I envision (and have already described, at least briefly) } sticky emulation for functions working. This all seems quite reasonable to me, particularly because the implementation appears to be a straightforward change to the code -- tends to imply that it fits naturally into the existing semantics. Nit-pick: The patch to Src/hashtable.c is a no-op. } Note that sticky emulation is not propagated to autoloaded functions, } neither when the autoload is set up nor when they are loaded What about zcompiled functions? Obviously there's no special case for them, but their treatment may be worth explanation at doc time. } - Sticky emulation does not cause options to be saved and reset while } executing another function with the same sticky emulation. I think this is fine. } - Functions without sticky emulation are not specially handled, so are } entered with no option changes, and do not have options reset on } exit except as normal shell handling, e.g. LOCAL_OPTIONS. I wouldn't expect this to behave any differently. } Someone can probably tell me if I should be keeping the RESTRICTED } and PRIVILEGED options when restoring options after executing a sticky } function, as for LOCAL_OPTIONS handling but not as for "emulate"; my } brain hurts. I think the answer is "no" because it looks more like the } latter case than the former, but it may not be that simple. I think "no" is also the right answer; I've always been a little puzzled about why those were made exceptions to LOCAL_OPTIONS. I think the answer to the latter is related to the fact that there's otherwise no way to force *any* option to persist across LOCAL_OPTIONS.