From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15261 invoked by alias); 4 May 2011 00:57:25 -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: 29146 Received: (qmail 2933 invoked from network); 4 May 2011 00:57:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110503175654.ZM16647@torch.brasslantern.com> Date: Tue, 03 May 2011 17:56:54 -0700 In-reply-to: Comments: In reply to Felipe Contreras "Re: zle messes up 'words' variable?" (May 3, 8:36pm) References: <110428203139.ZM11856@torch.brasslantern.com> <110502184235.ZM14465@torch.brasslantern.com> <110503073902.ZM15889@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Felipe Contreras Subject: Re: zle messes up 'words' variable? Cc: zsh-workers@zsh.org MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On May 3, 8:36pm, Felipe Contreras wrote: } Subject: Re: zle messes up 'words' variable? } } On Tue, May 3, 2011 at 5:39 PM, Bart Schaefer wrote: } > change the current values of these parameters. Any existing values } > will be hidden during execution of completion widgets; EXCEPT FOR } > COMPSTATE, THE PARAMETERS ARE RESET ON EACH FUNCTION EXIT (INCLUDING } > NESTED FUNCTION CALLS FROM WITHIN THE COMPLETION WIDGET) to the } > values they had when the function was entered. } > } > In other words, these variable are always local in all scopes, unless } > they are explicitly declared otherwise (which in this case requires } > the use of typeset -h). That's part of their special-ness, and is one } > of the things I assert is extremely unlikely to change. } } Except that 'words' is not really acting as local, and 'local' should } be considered 'declared otherwise'. That's part of the weirdness. "local" without -h has never changed the special properties of a zsh variable. It would be "weird" in a large number of other cases if it were to be "fixed" for this case. } +typeset -h words } complete -F _foo foo No, that's making words non-special at the wrong scope; it may work for your example because _foo never attempts to examine the special value of $words, but in practice you can't create a useful completion function without some reference to that special value. (However, I think it still fails for your example, because the typeset at global scope will be supplanted by the special local at completion scope. You have to wait until the local scope exists before you can hide it with "typeset -h".) Once the special "words" is hidden, the bash completion widgets can ignore it because for them, the relevant bits are passed in "$@"; but the _bash_complete wrapper that's installed by "complete -F" needs access to $words in order to create the arguments it passes to _foo. Hence the scope where my patch added typeset -h is only correct place outside the the function called as $OPTARG where words can become non- special without changing the arguments passed by that function call.