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

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxx> 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