Re: Bug: bracketed-paste-magic + ztcp causes wrong pasted contents for CJK payloads

[Chi Hsuan Yen <yan12125@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

Dear Zsh developers,

Today I've built Zsh again with commit 9642aeeaebd654565a045475d4d3ba101bfaec8f
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 <d.s@daniel.shahaf.name>
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. <takimoto-j@kba.biglobe.ne.jp> 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 ☺
>
> 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
>