From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16327 invoked by alias); 6 Jun 2015 06:51:20 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20251 Received: (qmail 21 invoked from network); 6 Jun 2015 06:51:16 -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=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=n0VYfw/Rwe6iZN1 nL8uH2y809w4=; b=kiMZNF4+/ws2TSlzoXBcYUrF6HSKQNuvs8ecXZFsy1ORgOY sDC434wfFoYMCzqD3ta2FAIJRlPSs7Y2TuC6xDrKJWdBuKYKc9dsWnwwjka/7lCi KjxUaYW+eCwXKcYY2++UwENG8jyRcCxRmUu612m06QnsoA41ChIpPu8mxO0U= X-Sasl-enc: 7nGIEVcuvBej2xufItQfVoue3JGHOj0/6ZTqFMQRNKM+ 1433572852 Message-ID: <557295F3.8040303@pobox.com> Date: Sat, 06 Jun 2015 02:40:51 -0400 From: Andrew Janke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Stephenson , Zsh Users Subject: Re: Three-byte UTF-8 chars and $functions References: <5567912F.9040004@pobox.com> <20150529121246.5d13e349@pwslap01u.europe.root.pri> In-Reply-To: <20150529121246.5d13e349@pwslap01u.europe.root.pri> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit That fixes it for me on OS X 10.9. (Sorry I didn't see this earlier; victim of an overzealous mail filter.) Thanks! Andrew On 5/29/15 7:12 AM, Peter Stephenson wrote: > On Thu, 28 May 2015 18:05:35 -0400 > Andrew Janke wrote: >> I'm seeing some odd behavior related to multibyte UTF-8 characters that >> I don't understand. Maybe one of you could help me figure out? I don't >> know if it's user error, incorrect behavior expectations on my part, or >> an actual character handling issue. > It's what we call "a bug". > > You may not have heard the expression before as it doesn't happen that > much round here. > > Sigh. > >> function foo () { echo '▸' } >> >> # But capture their string representations... >> foo_str="${functions[foo]}" >> >> # ...and in those strings, I see foo as 2 chars longer than bar > You know when you see something funny in a function and you're too > cowardly to change it so you just stick a comment about it there and > forget about it? This happens. > > See if there are still any remaining problems. > > pws > > diff --git a/Src/Modules/parameter.c b/Src/Modules/parameter.c > index 55157a9..04d4485 100644 > --- a/Src/Modules/parameter.c > +++ b/Src/Modules/parameter.c > @@ -410,11 +410,6 @@ getfunction(UNUSED(HashTable ht), const char *name, int dis) > } else > h = dyncat(start, t); > zsfree(t); > - /* > - * TBD: Is this unmetafy correct? Surely as this > - * is a parameter value it stays metafied? > - */ > - unmetafy(h, NULL); > > if (shf->redir) { > t = getpermtext(shf->redir, NULL, 1);