From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1183 invoked by alias); 31 May 2014 19:22:18 -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: 32639 Received: (qmail 16609 invoked from network); 31 May 2014 19:22:14 -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=TM7LSjVa c=1 sm=1 tr=0 a=BvYiZ/UW0Fmn8Wufq9dPrg==:117 a=BvYiZ/UW0Fmn8Wufq9dPrg==:17 a=NLZqzBF-AAAA:8 a=MJF4xiadgiEA:10 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=02rWKl3eAAAA:8 a=16F_4klcfDw9yRDGzIUA:9 a=CjuIK1q_8ugA:10 a=iVFYgQKhOj0A:10 Date: Sat, 31 May 2014 20:22:11 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Cc: 749969-forwarded@bugs.debian.org Subject: Re: Bug#749969: history no longer syncs immediately, INC_APPEND_HISTORY broken Message-ID: <20140531202211.396cd06e@pws-pc.ntlworld.com> In-Reply-To: <87d2eu5mmg.fsf@ft.bewatermyfriend.org> References: <20140531074936.GA9011@valiant.palfrader.org> <87d2eu5mmg.fsf@ft.bewatermyfriend.org> 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 Sat, 31 May 2014 11:21:59 +0200 Frank Terbeck wrote: > I think to enable both ways to be possible, there should be two options: > INC_APPEND_HISTORY that enables the original behaviour and (if the name > is agreeable) DELAY_INC_APPEND_HISTORY, that amends the behaviour of the > original option in the way that is reflected by the current behaviour. The issue is that, without rewriting the history, either the time taken for the command is wrong (that was the old case) or the command isn't written out to the history until it's finished (that's the current position). Writing the history to get the best of both worlds probably isn't beyond the bounds of 21st century science, but it's beyond my understanding of the history code at the moment. So at the moment having two options looks like the only way to allow you to achieve any one of the effects. I think the new behaviour could be INC_APPEND_HISTORY_TIME which puts it next to the original one and indicates why it exists. I haven't looked, but I don't think this ought to be too difficult --- there are still some reasons why you might have to deal with history at the original place anyway, so it should be possible to add an option test at that point as well as one at the later point. pws