From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28971 invoked by alias); 3 May 2011 08:05:42 -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: 29132 Received: (qmail 5688 invoked from network); 3 May 2011 08:05:39 -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.161.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=TPsVHUQw3cp5YbDX1jrpov7HzILNNrU01dQEaXQXSZg=; b=C9CJ5tih5zwGyIdGanPWR3UHOYTupUZsakqMiXAe3rlquoOHcd5gFIrkT4m14rqqao aRHPBqKKzvs9g6+1tutFGYMcQGQpDOzpx5b/6kT2V7XkYSNasQqnMykudcvo/4kTaagQ y6wZrMJHvW+UTAcBn+J1eFXWa4gaYQY8rwaj8= 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=OF8tsvpcB1Xn9RWIBoPi2L2P6fszpfvmEPIpoXfCI9sKz3Du9L05Ht+EyHojrISq1A L3guFqvg4pOFWsaAQWGWexTZxP0LVDrt/1A6+pQyThQmTN7E/J6lYw3vozfT48Vtmhek 7MG8PaCeQGDm83RmHq4tjO0Dinaw+cWV+eiy8= MIME-Version: 1.0 In-Reply-To: <110502184235.ZM14465@torch.brasslantern.com> References: <110428203139.ZM11856@torch.brasslantern.com> <110502184235.ZM14465@torch.brasslantern.com> Date: Tue, 3 May 2011 11:05:32 +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 Tue, May 3, 2011 at 4:42 AM, Bart Schaefer w= rote: > On May 2, =C2=A09:11pm, Felipe Contreras wrote: > } I am using bashcompinit, but the issue appears without it. > > Without bashcompinit, there is by definition not an issue. =C2=A0Or, if y= ou > prefer, you should have expected this issue to appear, because words is > documented as a special variable in completion function context. The fact that it's documented as a special variable doesn't mean that the behavior should be totally unexpected. 1) Without modifier Then 'words' can be re-used like any other variable. 2) With 'local' modifier Then modifying 'words' has an impact only on the current function, not on the scope where the variable was defined as local. 2.1) When using #compdef tag Then 'words' can be modified like any other variable. 3) With 'typedef -h' Then 'words' can be modified like any other variable. I was expecting an explanation of these discrepancies, and a way to globally make 'words' work as expected without having to replace each use of 'local' by 'typedef -h'. I don't think anybody knows what's going on, so nobody knows how to do that. In fact, this is probably a bug. > If what you want to discuss is ways to fix bashcompinit so that the > functions in bash completion work as expected, that's one thing. =C2=A0If > what you're asking is for the special-ness of "words" to be undone > for completion in general, that's so unlikely to happen as to not be > worth continuing. You are not good at compartmentalizing aren't you? If you fix the issue with my example, you fix the issue with bashcompinit. It's the same issue. Or "riddle" if that word makes you more comfortable. But if you want to mix the two things together, fine: --- #!bash autoload -U +X bashcompinit && bashcompinit set_vars () { cur=3D"foo" words=3D"foo" cwords=3D"foo" } _foo () { local cur words cwords set_vars echo "cur=3D${cur} words=3D${words} cwords=3D${cwords}" >> /tmp/comp_test.= txt } complete -F _foo foo --- cur=3Dfoo words=3D cwords=3Dfoo Now that is clearly a bug. --=20 Felipe Contreras