From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10569 invoked by alias); 29 Oct 2015 09:31:39 -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: 37010 Received: (qmail 9426 invoked from network); 29 Oct 2015 09:31:36 -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=-0.9 required=5.0 tests=BAYES_00,UC_GIBBERISH_OBFU autolearn=no autolearn_force=no version=3.4.0 X-AuditID: cbfec7f4-f79c56d0000012ee-df-5631e7742957 Date: Thu, 29 Oct 2015 09:31:31 +0000 From: Peter Stephenson To: Zsh hackers list Subject: Re: Bug: bracketed-paste-magic + ztcp causes wrong pasted contents for CJK payloads Message-id: <20151029093131.49241bde@pwslap01u.europe.root.pri> In-reply-to: <151028163814.ZM1379@torch.brasslantern.com> References: <151015172503.ZM30721@torch.brasslantern.com> <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> 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+NgFjrKLMWRmVeSWpSXmKPExsVy+t/xq7olzw3DDC426FscbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujLlPfjEW9LJVdLybyNrA+Jali5GTQ0LARGL+yuVMELaYxIV7 69m6GLk4hASWMkoc3P6JGcKZwSTx69xjKGcbo0Tn19OMIC0sAqoSV55PArPZBAwlpm6aDWaL CGhJ7Dh5EmyssECcxOXl35lBbF4Be4nv02aA2ZwClhJz9k9jhRj6hVni26LLYM38AvoSV/9+ grrJXmLmlTOMEM2CEj8m3wO7mxloweZtTawQtrzE5jVvwYYKCahL3Li7m30Co9AsJC2zkLTM QtKygJF5FaNoamlyQXFSeq6hXnFibnFpXrpecn7uJkZI4H7Zwbj4mNUhRgEORiUe3gVGhmFC rIllxZW5hxglOJiVRHiFbgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ887d9T5ESCA9sSQ1OzW1 ILUIJsvEwSnVwJjBdPxzblSUdZj6xhK93J2XpqkWnGdrPz55Q47By5iTFZzyP1xKT878wvBz teenyo/v5GQDekKXrDs30ZJVR/LJvB2WxySsDnUaXVBU+9i6TYLx/nJeuSDN+K1XFq34qj7/ SNJ0l8hfqd9YkxOeT19fb3bp9YPXq5hVg2RVnvr8Oso88cIu4TIlluKMREMt5qLiRADxpk7n WAIAAA== On Wed, 28 Oct 2015 16:38:13 -0700 Bart Schaefer wrote: > On Oct 28, 5:44pm, Peter Stephenson wrote: > } > } I wonder if the existing setsparam() etc. functions, which are currently > } just aliases or front-ends for assignsparam() etc. with no warnings, > } could be modified to add the flag based on the option? > > You mean modify the implementations, not the call signature, correct? Yes. > Testing of the WARNCREATEGLOBAL flag is pretty isolated at the moment > and there are a lot of calls to setsparam() et al. Exactly. I suspect they could all benefit --- I can't think of a case where this is actually wrong, only where you don't care. But WARNCREATEGLOBAL isn't supposed to care whether your care, only warn... pws