From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8808 invoked by alias); 17 Jul 2014 19:51:16 -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: 32883 Received: (qmail 4021 invoked from network); 17 Jul 2014 19:51:13 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Originating-IP: [86.6.157.246] X-Spam: 0 X-Authority: v=2.1 cv=U7AcDIbu c=1 sm=1 tr=0 a=BvYiZ/UW0Fmn8Wufq9dPrg==:117 a=BvYiZ/UW0Fmn8Wufq9dPrg==:17 a=NLZqzBF-AAAA:8 a=ngHcUYYLvfkA:10 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=vhj-6OSLAAAA:8 a=oPe_W6hzB6rlumCBB6IA:9 a=CjuIK1q_8ugA:10 a=02VRuEnyH80A:10 Date: Thu, 17 Jul 2014 20:51:07 +0100 From: Peter Stephenson To: Augie Fackler , zsh-workers@zsh.org Subject: Re: [PATCH] Fix loading of multi-line history entires from disk Message-ID: <20140717205107.582a8bc7@pws-pc.ntlworld.com> In-Reply-To: <20140717125841.GA27001@arthedain.local> References: <20140717125841.GA27001@arthedain.local> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 17 Jul 2014 08:58:41 -0400 Augie Fackler wrote: > Fixes the issue I posted about yesterday with > history-incremental-search-backward. I have no idea as to the > correctness of the fix, but my history file is written out in a way > that matches 4.3.x with this patch applied, and the behavior matches > again. You're right, it does work in both cases. The change that introduced this was to fix lines ending in two backslashes. That presumably needs something more sophisticated. But I'm not sure what --- the traditional doubling of backslashes to indicate a continuation line isn't syntactically unique, so I don't see how you can tell, short of checking for an extendedhistory introduction on the next line if that option's set, and obviously there's no guarantee it is. Specifically, for a continuation line % echo foo \ > bar \ > rod I get : 1405625973:0;echo foo \\ bar \\ rod and for three separate lines % echo foo \\ % echo bar \\ % echo rod \\ I get : 1405626360:0;echo foo \\ : 1405626364:0;echo bar \\ : 1405626453:0;echo rod \\ So I think we're stuck without breaking backward compatibility. Doubling all backslashes and looking for an odd number at the end would have worked better. pws