From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-34689-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 12438 invoked by alias); 9 Mar 2015 17:39:27 -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: 34689
Received: (qmail 7994 invoked from network); 9 Mar 2015 17:39:15 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	SPF_HELO_PASS autolearn=ham version=3.3.2
X-AuditID: cbfec7f5-b7fc86d0000066b7-84-54fdda28bdda
Date: Mon, 09 Mar 2015 17:39:07 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Aliasing separators (Re: grammar triviality with '&&')
Message-id: <20150309173907.08142605@pwslap01u.europe.root.pri>
In-reply-to: <150309100318.ZM12484@torch.brasslantern.com>
References: <20150304144756.GA27231@ypig.lip.ens-lyon.fr>
 <150304175112.ZM19818@torch.brasslantern.com>
 <20150305100638.55631238@pwslap01u.europe.root.pri>
 <150305090720.ZM8441@torch.brasslantern.com>
 <20150305174011.0be5a31e@pwslap01u.europe.root.pri>
 <150305174240.ZM8732@torch.brasslantern.com>
 <20150306094039.3d968c63@pwslap01u.europe.root.pri>
 <150306112628.ZM9769@torch.brasslantern.com>
 <20150307155252.75848f74@ntlworld.com>
 <150307131008.ZM17180@torch.brasslantern.com>
 <20150309114629.GF26461@xvii.vinc17.org>
 <20150309163309.44a00910@pwslap01u.europe.root.pri>
 <150309100318.ZM12484@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+NgFlrOLMWRmVeSWpSXmKPExsVy+t/xK7oat/6GGLRukrc42PyQyYHRY9XB
	D0wBjFFcNimpOZllqUX6dglcGVse/GYuWMlesfDvHtYGxmesXYycHBICJhKr5hxjgrDFJC7c
	W8/WxcjFISSwlFFi/ooTrBDOEiaJQ79uQTnbGCUmL9vEDNLCIqAqsWDSJrB2NgFDiambZjOC
	2CIC4hJn155nAbGFBZwljs05DVbPK2Avsb5rJ9hqTgEriY0fO1gghjaxSrzb2M0OkuAX0Je4
	+vcT1E32EjOvnGGEaBaU+DH5HthQZgEtic3bmlghbHmJzWvegi0QElCXuHF3N/sERqFZSFpm
	IWmZhaRlASPzKkbR1NLkguKk9FwjveLE3OLSvHS95PzcTYyQwP26g3HpMatDjAIcjEo8vA0V
	f0OEWBPLiitzDzFKcDArifA67gUK8aYkVlalFuXHF5XmpBYfYmTi4JRqYHRb5f38cXzlvo4Q
	QV2TbP49CcEHpvOuz9g9OTInNzdbJy809doWy1lKv56JVKgkz6719Um5Y2h1Wnj5h/vc80Ny
	XB/9sZh1+6f9QxO3t2a/X7mZiJro82gePVv3O9w5nNv69vwshdv1DNtl8o59SX3lknH04u9j
	uhtTM1a6fM19rjTF27PLQomlOCPRUIu5qDgRAL2m7Js6AgAA

On Mon, 9 Mar 2015 10:03:18 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Mar 9,  4:33pm, Peter Stephenson wrote:
> }
> } What happens to white space certainly seems to be central to the things
> } Bart is most worried about --- both what goes into and what comes out of
> } the alias.  Possibly soluble with enough checks and management of
> } token expansion.  Are we motivated enough to look into the necessary
> } code to improve this?  We still have the option of backing it off
> } before anyone outside the mailing list notices.
> 
> My vote (perhaps obviously) would be to back it out, fix the issue with
> "{" / catenation and the history, and then consider whether aliasing of
> other tokens can be re-introduced.

I'm not sure what the last bit means, but the only requirement for
backing it off remains updating the documentation so it properly
describes what can and can't be aliased.

pws