From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-37010-mason-zsh=primenet.com.au@zsh.org>
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 <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
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 <p.stephenson@samsung.com>
To: Zsh hackers list <zsh-workers@zsh.org>
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:
 <CAMNjDR3xZP9wCuYd-3uoBBPVLa-WPa8rAgkVbPxPOC_gyZPSJg@mail.gmail.com>
 <CAH+w=7ZJRmbk7QzprgAqL8VWf0zPYxTcoUaZOtzv8aHp4Un6LA@mail.gmail.com>
 <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 <schaefer@brasslantern.com> 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