From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22600 invoked by alias); 13 Oct 2012 04:02:03 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30731 Received: (qmail 13145 invoked from network); 13 Oct 2012 04:01:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <121012210144.ZM691@torch.brasslantern.com> Date: Fri, 12 Oct 2012 21:01:44 -0700 In-reply-to: <20121011205338.02c8d76b@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: emulate with options other than -c is broken" (Oct 11, 8:53pm) References: <20121006000125.354e8448@pws-pc.ntlworld.com> <20121007202606.5bdd17bb@pws-pc.ntlworld.com> <20121011205338.02c8d76b@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: emulate with options other than -c is broken MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 11, 8:53pm, Peter Stephenson wrote: } Subject: Re: emulate with options other than -c is broken } } The next question is, do we want to use this for functions autoloaded } by the completion system? The argument against is that it changes } the behaviour Hmm. The difficulty I see with this is that compinit is used to load widget functions (#compdef -k / -K) and other helpers (#autoload) for which the set of $_comp_options do not necessarily apply. Futhermore, I know I use #autoload in files that don't necessarily have anything to do with completion, just because I know compinit will pick them up for me. Pulling those setopts out of $_comp_setup into an emulate wrapper around the autoload call in compinit (if that is indeed what you contemplate here) would apply them too broadly. So we'd probably need another #compdef switch to activate emulation mode, and then go through all the completion functions to determine which ones should have it. } (we'd probably need to enter zsh emulation plus set a few options, } rather than just set explicit options --- but note the property that } if the emulation is the same we do allow option changes to propagate } between functions, as at present) I wonder if "the same" is the best comparison to make here. As an example, if I write emulate zsh -c 'doglob() { print * }' it may not be my intention to prevent the extendedglob option from being "passed down" from a calling context. On the other hand emulate zsh -o no_extendedglob -c '...' clearly means extendedglob should be forced off. This would mean that the behavior of non-sticky functions follows naturally -- when the set of options turned on/off is empty, any/all options are "inherited". However, that would mean storing not just the state of the options, but the sense of how they arrived at that state, which is a lot of overhead. And I guess the caller could sneak extendedglob through by doing emulate zsh -c 'setopt extendedglob; doglob' because then the sticky bits are the same but I've changed extendedglob after the fact. } The argument in favour is the behaviour is easier to document because } it's based on emulations, and the function behaviour is guaranteed } wherever it's loaded or called, not just from somewhere under } _main_complete Hmm, maybe. The function behavior would be guaranteed as long as you didn't autoload those functions before compinit had a chance to do so. But I suspect a lot of people autoload everything in $fpath, and that at least some of them do so before calling compinit, particulary the people who zcompile their entire function set. So we'd still need to perform all those setopts in _main_complete et al. } (remember what got me into this was the fact that forcing _path_files } to autoload outside the completion system gave an error). Another potentially interesting question: How should/does this interact with zcompile? For example the -U (noaliases) option is recorded in the ZWC file, why shouldn't other option state be compilable, too?