From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12668 invoked by alias); 9 Mar 2015 16:33:51 -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: 34686 Received: (qmail 13437 invoked from network); 9 Mar 2015 16:33:36 -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: cbfec7f4-b7f126d000001e9a-ee-54fdcac95917 Date: Mon, 09 Mar 2015 16:33:09 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Aliasing separators (Re: grammar triviality with '&&') Message-id: <20150309163309.44a00910@pwslap01u.europe.root.pri> In-reply-to: <20150309114629.GF26461@xvii.vinc17.org> 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> 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+NgFlrCLMWRmVeSWpSXmKPExsVy+t/xq7onT/0NMXh8Ut7iYPNDJgdGj1UH PzAFMEZx2aSk5mSWpRbp2yVwZay7LFGwjaui5+c/lgbGhRxdjJwcEgImEi+Xf2KFsMUkLtxb z9bFyMUhJLCUUeLiwz2sEM4SJomm978YQaqEBLYxSkyZJQdiswioSszf8pgFxGYTMJSYumk2 WI2IgLjE2bXnweLCAs4Sx+acZgaxeQXsJSZOXMkEYnMKmEq0ftzOAjFzDovEvFVSIDa/gL7E 1b+fmCAuspeYeeUMI0SvoMSPyffA6pkFtCQ2b2tihbDlJTavecsMMUdd4sbd3ewTGIVmIWmZ haRlFpKWBYzMqxhFU0uTC4qT0nMN9YoTc4tL89L1kvNzNzFCQvbLDsbFx6wOMQpwMCrx8DZU /A0RYk0sK67MPcQowcGsJMLruBcoxJuSWFmVWpQfX1Sak1p8iJGJg1OqgbGlfDvj9nOLkk/d 87eaoqL0hP1p6w6VCrEMGf/MSz1nIjyvvla1q6s8Yfk+abJSXQLf/7uzrXYnJfK8LGv8qK9g YFXDurn4KOfL9HiXJb0KBxnYOpKmqIU/OMxt31qQzBB5+ZpzUP2S9OrE5dveabJPn50eo6bK 6nyMi+Pzwc8vX5i9lv5/SImlOCPRUIu5qDgRAM0APnA3AgAA On Mon, 9 Mar 2015 12:46:29 +0100 Vincent Lefevre wrote: > On 2015-03-07 13:10:08 -0800, Bart Schaefer wrote: > > Actually, that helped me to put some sort of explanation around my > > intuition of how aliasing should work: > > > > A token may be expanded as an alias only if doing so cannot change the > > lexical interpretation of any tokens that may appear adjacent to it. > > > > This emphasizes that "{this" expanding to "{ foothis" in the example at > > the tail of my previous message, is a bug: The interpretation of "this" > > has been changed, and the internal inconsistency is manifest when you > > examine what has been stored in the history. > > Can't this be solved by adding a space during alias expansion? 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. ("We" mostly meaning the people doing the work, which for present purposes means Bart and me. People not doing any work are much more easily motivated :-/) pws