From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5373 invoked by alias); 3 Nov 2015 16:31:38 -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: 37053 Received: (qmail 24011 invoked from network); 3 Nov 2015 16:31:37 -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,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NpZgRdptmHQd9wgkeg9J8Cv9A2JtYZwKmAev6+z1CDw=; b=TlO8U0Ux50JjRbQdaqz7rx+kRVU/jSlb+F6FAyo7rctIZkVHDiwiZuMzKEgT9BQTjH oegl+ymqByEhQHNlivkzlf+fqe9AAnWIYzJ2En2IYubMiUxmMQbnerHOvdDud/HDF92B LFyacnJZfjAti2+VS0jRMGFV7uTak9c38/+CX+EHLZ8w65RAefdbNd1lRsn4WVV+tSoE AkAp2poYeKThHINYV4oQOEtRS/0obl/rTk8JosrOD+DYMuzjA3oDSA8Refg3rL3wmAiY oV4bQrdRUGVYDGDfdaHyTfVZcP8YXIFFJT+qExbkBzVZelxgAwI5G1rUI72ziEATaxs5 brYw== MIME-Version: 1.0 X-Received: by 10.129.44.138 with SMTP id s132mr21403238yws.306.1446568289494; Tue, 03 Nov 2015 08:31:29 -0800 (PST) In-Reply-To: <20151030150203.GB1462@tarsus.local2> References: <151027194317.ZM17099@torch.brasslantern.com> <151027202340.ZM17146@torch.brasslantern.com> <20151028093504.756c22b1@pwslap01u.europe.root.pri> <151028100744.ZM18361@torch.brasslantern.com> <20151028174448.70594180@pwslap01u.europe.root.pri> <151028163814.ZM1379@torch.brasslantern.com> <20151029093131.49241bde@pwslap01u.europe.root.pri> <20151029145143.6b3830a7@pwslap01u.europe.root.pri> <0D7C93CF-C84C-43BF-B7ED-4A868F04D401@kba.biglobe.ne.jp> <20151029165625.67eb2e43@pwslap01u.europe.root.pri> <20151030150203.GB1462@tarsus.local2> Date: Wed, 4 Nov 2015 00:31:29 +0800 Message-ID: Subject: Re: Bug: bracketed-paste-magic + ztcp causes wrong pasted contents for CJK payloads From: Chi Hsuan Yen To: Daniel Shahaf Cc: Peter Stephenson , Zsh hackers list Content-Type: multipart/alternative; boundary=001a1141e56a09ee980523a56d83 --001a1141e56a09ee980523a56d83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Zsh developers, Today I've built Zsh again with commit 9642aeeaebd654565a045475d4d3ba101bfa= ec8f and it works like a charm. CJK payloads can be pasted correctly with either the minimal buggy zshrc or the current one I'm using. Much gratitude for the work! Best Regards, Yen Chi Hsuan On Fri, Oct 30, 2015 at 11:02 PM, Daniel Shahaf wrote: > Peter Stephenson wrote on Thu, Oct 29, 2015 at 16:56:25 +0000: > > On Fri, 30 Oct 2015 01:25:49 +0900 > > Jun T. wrote: > > > E01options.ztst also need be updated; otherwise it fails as follows: > > > > > > *** /tmp/zsh.ztst.err.65239 Fri Oct 30 00:54:52 2015 > > > --- /tmp/zsh.ztst.terr.65239 Fri Oct 30 00:54:52 2015 > > > *************** > > > *** 1,3 **** > > > --- 1,4 ---- > > > fn:3: scalar parameter foo1 created globally in function > > > fn:5: scalar parameter foo1 created globally in function > > > fn:15: math parameter foo5 created globally in function fn > > > + fn:15: numeric parameter foo5 created globally in function > > > > Hmmm... I must have been asleep when the math test was added, since > > there's no reason at all why it should be inconsistent with the others. > > Either report the function or not. > > > > -?fn:3: scalar parameter foo1 created globally in function > > -?fn:5: scalar parameter foo1 created globally in function > > -?fn:15: math parameter foo5 created globally in function fn > > +?fn:3: scalar parameter foo1 created globally in function fn > > +?fn:5: scalar parameter foo1 created globally in function fn > > +?fn:15: numeric parameter parameter foo5 created globally in function = fn > > Thanks for improving it =E2=98=BA > > I'll fix the "numeric parameter parameter" thing. > > > This ports the code to report the function. The math-specific code is > > no longer needed now we have a check in setnparam(). I've been > > overcautious since I can't see why we'd fail to find a function > > on the trace stack if locallevel is non-zero. > > I can't see when that would happen, either; the reason for the NULL > checks might be, more than anything else, that I wasn't familiar with > the C funcstack data structure. > > Thanks, > > Daniel > --001a1141e56a09ee980523a56d83--