From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12823 invoked from network); 19 Jan 2009 21:22:01 -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; 19 Jan 2009 21:22:01 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 90437 invoked from network); 19 Jan 2009 21:21:53 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 19 Jan 2009 21:21:53 -0000 Received: (qmail 3235 invoked by alias); 19 Jan 2009 21:21:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26369 Received: (qmail 3217 invoked from network); 19 Jan 2009 21:21:47 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 19 Jan 2009 21:21:47 -0000 Received: from mx.spodhuis.org (redoubt.spodhuis.org [193.202.115.177]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 24D4B80271F0 for ; Mon, 19 Jan 2009 22:21:42 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=d200807; d=spodhuis.org; h=Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=dZnFOYt2ScsMXxCDNMg870Ny5442v5UJnB+bg2d1Ut1E+5KM9Wa6aYWPglv3u3gxDLCWYufkiT2qH9u3HtZFD6jSM9jHBf3pvv8zM0WXQECcuqEMgahPC1n4ZL++0syAP/jt03/tSgq4V/KyHXkgTafGFG56CBnpgPTEoUSMv+w=; Received: by smtp.spodhuis.org with local id 1LP1Yv-000Hmk-E5; Mon, 19 Jan 2009 21:21:37 +0000 Date: Mon, 19 Jan 2009 13:21:37 -0800 From: Phil Pennock To: zsh-workers@sunsite.dk Subject: Re: sourcing a sh file in zsh Message-ID: <20090119212137.GA68041@redoubt.spodhuis.org> Mail-Followup-To: zsh-workers@sunsite.dk References: <090116075615.ZM21871@torch.brasslantern.com> <200901161939.54651.arvidjaar@newmail.ru> <090116102934.ZM22119@torch.brasslantern.com> <20090117035923.GA64953@redoubt.spodhuis.org> <090116210045.ZM22623@torch.brasslantern.com> <20090117055559.GA60339@redoubt.spodhuis.org> <090117121501.ZM8940@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <090117121501.ZM8940@torch.brasslantern.com> X-Virus-Scanned: ClamAV 0.92.1/8877/Mon Jan 19 11:18:35 2009 on bifrost X-Virus-Status: Clean On 2009-01-17 at 12:15 -0800, Bart Schaefer wrote: > This gets very tricky, however, when applied to functions that are > actually designed for zsh. An implicit preset of options implies an > implicit restore later, but a zsh function which deliberately does > NOT "setopt localoptions" is expecting any setopt it executes to > persist after the function exits. It'll be complicated to keep track > of which options should be restored because of implicit preset, and > which ones should not be restored because of explicit change. True. My usage scenario was too narrow -- the functions being defined would never use setopt since they'd be non-zsh functions, except at the top-level where this new feature would be enabled. In a sense, I'm creating something akin to a namespace, but being more of a setopt-value-space. I'm wondering if it's worth looking at this from a different angle and whether or not there's something along the lines of a namespace concept which it's worth implementing, with setopts being local to a namespace and being able to source a script in another namespace, created at source time. Now, a separate pair of items of things I should explore when I have time, as approaches, tie into this but I hadn't noticed the connection before (down-side of what is mostly an unordered collection of crazy ideas worked in with small nits): ----------------------------8< cut here >8------------------------------ Namespaced variables? Default is 'main' znamespace valid-var-name to change current, reverts on return from scope? Case-insensitive, so that you can use consistent capitalisation for the entire qualified var-name ${namespace.varname} to get others (braces mandatory) All zsh builtin params also available in 'zsh' namespace. So ${ZSH.SECONDS}, ${zsh.fpath}, etc. All existing vars bound as before. Can we handle multiple names bound to exact same var, besides the tied FOO/foo case? -- only the namespace case-insensitive ZSHZLE.* for widget variables which persist, such as killring? How to handle assignment? Make dot valid at parse-time separately? Alternatively: Methods via var.method, so that scalarvar.charlen and sv.bytelen give results. Have special namespace variables which have the method return any variable within that namespace so that you can chain. Thus ${zsh.fpath.count} gives the number of elements in the zsh fpath array. ----------------------------8< cut here >8------------------------------ (DISCLAIMER: my notes contain crazy ideas) So, is it instead a case of making setopts namespace-bound, thinking more carefully about syntax than my rough scratchings above, moving much of completion into a separate namespace and then have functions called from outside the namespace switch namespace upon invocation and restore on departure, mechanics much as I described for setopt, but abstracted out to a container for whatever semantics we want to make switchable? Please, bang this idea about a bit, shoot down or refine as appropriate. -Phil