From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25900 invoked from network); 18 Mar 2005 18:19:35 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Mar 2005 18:19:35 -0000 Received: (qmail 1050 invoked from network); 18 Mar 2005 18:19:29 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Mar 2005 18:19:29 -0000 Received: (qmail 8549 invoked by alias); 18 Mar 2005 18:19:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21013 Received: (qmail 8536 invoked from network); 18 Mar 2005 18:19:26 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Mar 2005 18:19:26 -0000 Received: (qmail 756 invoked from network); 18 Mar 2005 18:19:26 -0000 Received: from dsl3-63-249-88-2.cruzio.com (HELO dot.blorf.net) (63.249.88.2) by a.mx.sunsite.dk with SMTP; 18 Mar 2005 18:19:22 -0000 Received: by dot.blorf.net (Postfix, from userid 1000) id B2211AB5B; Fri, 18 Mar 2005 10:19:21 -0800 (PST) Date: Fri, 18 Mar 2005 10:19:21 -0800 From: Wayne Davison To: Bart Schaefer Cc: zsh-workers@sunsite.dk Subject: Re: revisiting history-file rewriting Message-ID: <20050318181921.GF5500@blorf.net> References: <20050316204059.GA1298@blorf.net> <1050317180338.ZM32687@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1050317180338.ZM32687@candle.brasslantern.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 On Thu, Mar 17, 2005 at 06:03:38PM +0000, Bart Schaefer wrote: > I'm OK with this, though I think the documentation should explain in > more detail how it interacts with APPEND_HISTORY, INC_APPEND_HISTORY, > and SHARE_HISTORY. Yeah, my docs were pretty minimal. > We already have HIST_APPEND; while we're at it, perhaps we add > HIST_APPEND_INC, HIST_SHARE, and OVERWRITE_HISTORY with appropriate > aliasing? I don't like OVERWRITE_HISTORY because it sounds like something that conflicts with APPEND_HISTORY. Perhaps my option name needs to be improved -- how about HIST_WRITE_IN_PLACE? That seems to better indicate that it is effecting how the history file is written out rather than affecting how data is put into the history file. As for the other aliases, I wouldn't mind seeing them added. ..wayne..