From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-37095-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 13786 invoked by alias); 12 Nov 2015 09:46:36 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 37095
Received: (qmail 6451 invoked from network); 12 Nov 2015 09:46:33 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.0
X-AuditID: cbfec7f4-f79c56d0000012ee-d7-56445ff56583
Date: Thu, 12 Nov 2015 09:46:28 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: PATCH: nested ${(P)} (formerly SHWORDSPLIT and leading spaces)
Message-id: <20151112094628.7345465b@pwslap01u.europe.root.pri>
In-reply-to: <20151111215541.4a1fb149@ntlworld.com>
References: <87a8qr75za.fsf@gmail.com>
 <20151106170007.5196bd5e@pwslap01u.europe.root.pri>
 <20151107174255.74054b28@ntlworld.com>
 <151107114314.ZM24285@torch.brasslantern.com>
 <20151108181833.574cf0d6@ntlworld.com>
 <20151111174911.4384bf73@pwslap01u.europe.root.pri>
 <20151111215541.4a1fb149@ntlworld.com>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsVy+t/xy7pf413CDK6c17U42PyQyYHRY9XB
	D0wBjFFcNimpOZllqUX6dglcGS3b/zEWHGGv2Nbzm7mB8RNrFyMnh4SAicT6rxOZIWwxiQv3
	1rN1MXJxCAksZZR43nUcypnBJDH5+nEWCGcbo8TBv3/A2lkEVCXevP3HDmKzCRhKTN00mxHE
	FhEQlzi79jwLiC0s4C1x+/hvsDivgL3Erpe7mEBsTgFjiW8HDrBDDN3LJHHpVDvYHfwC+hJX
	/35igrjJXmLmlTNQzYISPybfAxvKLKAlsXlbEyuELS+xec1bsF4hAXWJG3d3s09gFJqFpGUW
	kpZZSFoWMDKvYhRNLU0uKE5KzzXUK07MLS7NS9dLzs/dxAgJ3C87GBcfszrEKMDBqMTDO2Gm
	c5gQa2JZcWXuIUYJDmYlEd4CL5cwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxzd70PERJITyxJ
	zU5NLUgtgskycXBKNTDm8M6tr9kxf7Px533KoiffiLHlv9+S8nl506vqGEfF/Ox8pp5O43D2
	x9Nep9by7Li0gbvnuJh9cabFgpvey9It9D+qRni4yHxvutTdorGsgS++47Vbys3wbE7O/rmb
	tybPqnk+/3Ppp5dzT+z/e+z9VZ0zM88uO3ztxMWaby2Za/hkezjc3zMrsRRnJBpqMRcVJwIA
	t2w9HlgCAAA=

On Wed, 11 Nov 2015 21:55:41 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> With a little more tweaking, nested references work naturally, if
> "naturally" is the word.  See final test.
>...
> +  testfn() {
> +    local one=two
> +    local two=three
> +    local three=four
> +    local -a four=(all these worlds belong to foo)
> +    print ${${(P)${(P)${(P)one}}}}
> +    print ${${(P)${(P)${(P)one}}}[3]}
> +  }

Well, one thing that isn't natural is that when you're relying on the
new logic you need that extra ${...} wrapper even in the first of the
two cases to trigger the recursive (P).  Normally a surrounding level
with no flags, modifications or subscripts has no effect.  You don't
need that for one (P) at the top level, ${(P)...}, because that's going
a different path through the code.

Either I should work out how to fix that or document the difference.
I can't imagine anyone is going to lose sleep.

pws