From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-36695-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 28525 invoked by alias); 29 Sep 2015 08:44:42 -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: 36695
Received: (qmail 21045 invoked from network); 29 Sep 2015 08:44:41 -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-a1-560a4f7662ed
Date: Tue, 29 Sep 2015 09:44:36 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Substitution ${...///} slows down when certain UTF character occurs
Message-id: <20150929094436.32b62692@pwslap01u.europe.root.pri>
In-reply-to: <20150928202312.6679b38e@ntlworld.com>
References:
 <CAKc7PVBuCuLux8WhBORuYo_vQUQ18OP-XMQXWdYkL84pFLt+LQ@mail.gmail.com>
 <150926134410.ZM17546@torch.brasslantern.com>
 <CAKc7PVC_12=vVfCKGhxd9L06=+o0-r7Zti+Ag1xnv8C4tEwvmQ@mail.gmail.com>
 <150927091121.ZM25721@torch.brasslantern.com>
 <20150928095142.385a33eb@pwslap01u.europe.root.pri>
 <20150928202312.6679b38e@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+NgFjrMLMWRmVeSWpSXmKPExsVy+t/xK7pl/lxhBp0nVS0ONj9kcmD0WHXw
	A1MAYxSXTUpqTmZZapG+XQJXxrHWq0wF+1grlt5qYG9gPMDSxcjJISFgIvH53RkoW0ziwr31
	bF2MXBxCAksZJa4vvM8C4cxgklgxaQ4jhLONUWL9/EVMIC0sAqoS2/4uZwWx2QQMJaZums0I
	YosIiEucXXseqJuDQ1ggQGL352AQk1fAXmLK5myQCk4BY4mm2yfZIUbeYJJ4sfsY2Bh+AX2J
	q38/MUFcZC8x88oZsJG8AoISPybfA7uUWUBLYvO2JlYIW15i85q3zCC2kIC6xI27u9knMArN
	QtIyC0nLLCQtCxiZVzGKppYmFxQnpeca6hUn5haX5qXrJefnbmKEBO2XHYyLj1kdYhTgYFTi
	4e2YwBkmxJpYVlyZe4hRgoNZSYT3jDNXmBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeubvehwgJ
	pCeWpGanphakFsFkmTg4pRoYpfavui54zO/uOolLRoludw3k5kXM8BddY3cjdM33W2GvZJla
	7d4s65wqZ7v/IZ9ktdBf9fQNTXtVFx665f/t4fJTV2sWr8jpvriA+eQ7l29h7qd37f8yy8th
	J09HZ+xrHXa92TVa0/z/eT/fKHFY75ZbZMVD9trsqanqp7Rb5PQa/H2E7GfuVGIpzkg01GIu
	Kk4EAMKb2c1WAgAA

On Mon, 28 Sep 2015 20:23:12 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> This does the back-end work, with a patstralloc structure that allows
> you to maintain information about an unmetafied string over calls to
> pattrylen() and pattryrefs().

Bart pointed out I didn't actually attach the patch, but it's now
committed in f9d7651c25.  No noticeable change of behaviour is expected
yet.  I started looking at the front end last night; it's not difficult,
just quite a bewildering number of things to switch to unmetafied.
Overall it should actually be slightly simpler after the change because
we were remembering quite a lot of positions as unmetafied already.

pws