From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25318 invoked by alias); 18 Jul 2014 03:08:54 -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: 32886 Received: (qmail 7727 invoked from network); 18 Jul 2014 03:08:52 -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 From: Bart Schaefer Message-id: <140717200824.ZM4640@torch.brasslantern.com> Date: Thu, 17 Jul 2014 20:08:24 -0700 In-reply-to: <201407171958.s6HJwj5f003940@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: [PATCH] Fix loading of multi-line history entires from disk" (Jul 17, 8:58pm) References: <201407171958.s6HJwj5f003940@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: [PATCH] Fix loading of multi-line history entires from disk MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jul 17, 8:58pm, Peter Stephenson wrote: } Subject: Re: [PATCH] Fix loading of multi-line history entires from disk } } Bart Schaefer wrote: } > So, check out the following. This includes Augie's patch (backs out } > 30433) and adds an attempt at changing the output (appends a space after } > an even number of backslashes appearing at the end of an entry). } } That seems as minimal and compatible as we're going to get. OK, I'm going to go ahead and push 32882 while we discuss alternate end-of-entry markers. } Is it worth appending something syntactically null but a little more } complicated that we can strip on input with little likelihood of } stepping on anyone's toes? " ; "? Unless we do attempt that, appending } a simple space is as good as anything. We could follow the examples of extended-history and _complete_debug to use something that begins with ";:". E.g. we could do something like ";: ENDS_WITH_BACKSLASH" but that's not really "syntactically null" though it is semantically null.