From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9920 invoked by alias); 5 May 2011 14:48:57 -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: 29150 Received: (qmail 15498 invoked from network); 5 May 2011 14:48:55 -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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.214.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kA4Gp7TDW+QJpctJIaObX3fLz8skogE/J0yoFSS3dcw=; b=tgHh6kFZ572nLu2KAJd4gQ9exc/QcEsQaMKWdtm8c9WSaHm/BMqw484kdIvMqNaFpL /qobSNtY4XGPzHKazfg5+jvSLWwP3PKvu8GP29AtVmwSr/6RxbzdfwHX8NPJOwU+MPki Jz0vnV+WpBT3rW2A3OkSAiGD3vUA7ZLsDDz6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Szw4N2A+vPUR1CXgaD70JhUxCGCBqHIv4dkCab7ejo3wPppXXMRS1ESO3kxJY38nsN iycomFJjDiiB2QyG3nP83Opi8o9505GB9xrhuqKXqPcMO7erU+V7yiBpLRqXsAqsft87 YTL9ouevgL5ikFqbD0tV5DLQh5I7+Xh+Xo5BA= MIME-Version: 1.0 In-Reply-To: <110503175654.ZM16647@torch.brasslantern.com> References: <110428203139.ZM11856@torch.brasslantern.com> <110502184235.ZM14465@torch.brasslantern.com> <110503073902.ZM15889@torch.brasslantern.com> <110503175654.ZM16647@torch.brasslantern.com> Date: Thu, 5 May 2011 17:48:49 +0300 Message-ID: Subject: Re: zle messes up 'words' variable? From: Felipe Contreras To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 4, 2011 at 3:56 AM, Bart Schaefer w= rote: > On May 3, =C2=A08:36pm, Felipe Contreras wrote: > } Subject: Re: zle messes up 'words' variable? > } > } On Tue, May 3, 2011 at 5:39 PM, Bart Schaefer wrote: > } > =C2=A0 =C2=A0change the current values of these parameters. Any exist= ing values > } > =C2=A0 =C2=A0will be hidden during execution of completion widgets; E= XCEPT FOR > } > =C2=A0 =C2=A0COMPSTATE, THE PARAMETERS ARE RESET ON EACH FUNCTION EXI= T (INCLUDING > } > =C2=A0 =C2=A0NESTED FUNCTION CALLS FROM WITHIN THE COMPLETION WIDGET)= to the > } > =C2=A0 =C2=A0values 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). =C2=A0That'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. =C2=A0It would be "weird" in a large number of other cases if i= t > were to be "fixed" for this case. > > } +typeset -h words > } =C2=A0complete -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. =C2=A0You 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. You are right, however, it does work in git[1]. Here's a more complete example to what git is doing, and my proposed 'typeset -h' workaround. --- #!bash autoload -U +X bashcompinit && bashcompinit set_vars () { cur=3D${COMP_WORDS[COMP_CWORD]} words=3D("${COMP_WORDS[@]}") cwords=3D$COMP_CWORD } _foo_bar () { local cur words cwords set_vars echo "foo bar: cur=3D${cur} words=3D${words} cwords=3D${cwords}" >> /tmp/comp_test.txt } _foo () { typeset -h words local cur words cwords set_vars echo "foo: cur=3D${cur} words=3D${words} cwords=3D${cwords}" >> /tmp/comp_= test.txt _foo_bar } complete -F _foo foo --- [1] http://mid.gmane.org/1304605458-1483-1-git-send-email-felipe.contreras@= gmail.com --=20 Felipe Contreras