From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21902 invoked from network); 3 Jun 1999 06:37:15 -0000 Received: from postoffice.telstra.net (139.130.4.7) by ns1.primenet.com.au with SMTP; 3 Jun 1999 06:37:15 -0000 Received: from sunsite.auc.dk (sunsite.auc.dk [130.225.51.30]) by postoffice.telstra.net (8.8.8/8.8.8) with SMTP id QAA20890 for ; Thu, 3 Jun 1999 16:19:47 +1000 (EST) (envelope-from zsh-workers-return-6447-mason-zsh=primenet.com.au@sunsite.auc.dk) Received: (qmail 23339 invoked by alias); 3 Jun 1999 06:34:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6447 Received: (qmail 22783 invoked from network); 3 Jun 1999 06:24:35 -0000 From: "Bart Schaefer" Message-Id: <990603061922.ZM2764@candle.brasslantern.com> Date: Thu, 3 Jun 1999 06:19:22 +0000 In-Reply-To: <199906020955.CAA04266@bebop.clari.net> Comments: In reply to Wayne Davison "PATCH: 3.0.6-pre-3: mainly history bug fixes" (Jun 2, 2:55am) References: <199906020955.CAA04266@bebop.clari.net> X-Mailer: Z-Mail (5.0.0 30July97) To: Wayne Davison Subject: Re: PATCH: 3.0.6-pre-3: mainly history bug fixes Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 2, 2:55am, Wayne Davison wrote: } Subject: PATCH: 3.0.6-pre-3: mainly history bug fixes } } I believe I've managed to distill most of the bug fixes that were } included in my previous history changes into a separate patch for } 3.0.6. I haven't had much of a chance to test this yet, but since } most of this is lifted from my previous changes, it should be OK. } } Most of these changes were originally lifted from the 3.1.x source. Pardon my paranoia, but ... Something I don't want to accidentally do is fold in the history search change (whole words at beginning of line) that caused so much complaint and eventual back-patching. I don't *think* I see it in here anywhere, but if you can reassure me, please do. } One non-bugfix that is included here is the change I made to the } EXTENDED_HISTORY output format where it writes the finish time in } elapsed seconds instead of epoch seconds -- I figured if this is } going to change in 3.1.x, we might as well get it going in 3.0.6 too. I hadn't thought much about this before, but what's going to happen when somebody with this option set fires up a new zsh and it loads his existing old-format .zhistory? All the timestamps are going to look like garbage, aren't they? Seems to me that a change like this should be written in different syntax, so that there's no chance of confusing the old numbers for the new. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com