From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15908 invoked from network); 4 Jun 1999 04:39:33 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Jun 1999 04:39:33 -0000 Received: (qmail 22424 invoked by alias); 4 Jun 1999 04:39:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6456 Received: (qmail 22417 invoked from network); 4 Jun 1999 04:39:23 -0000 From: "Bart Schaefer" Message-Id: <990604043844.ZM4317@candle.brasslantern.com> Date: Fri, 4 Jun 1999 04:38:43 +0000 In-Reply-To: Comments: In reply to Wayne Davison "Re: PATCH: 3.0.6-pre-3: mainly history bug fixes" (Jun 3, 8:11pm) References: 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 3, 8:11pm, Wayne Davison wrote: } Subject: Re: PATCH: 3.0.6-pre-3: mainly history bug fixes } } On Thu, 3 Jun 1999, Bart Schaefer wrote: } > Something I don't want to accidentally do is fold in the history } > search change (whole words at beginning of line) } } Quite correct, I did not include that change, nor any history change } that was not a bug fix or a code optimization. Thank you (both for doing it and reassuring me about it). } > what's going to happen when somebody with this option set fires up } > a new zsh and it loads his existing old-format .zhistory? } } The new code is smart enough to treat a finish length that is >= the } start time as the old format. Aha. } Going back from a new shell with this new EXTENDED_HISTORY format to } an old shell without it can cause the finish times to read in as } very early dates, but I wasn't particularly concerned about this. } Do you feel differently? I'm thinking about it ... of course one hopes that there won't be any reason to go backwards ... it's impossible to make such a change in a forwards-compatible way (such that the old version won't be confused) so there's no point in doing more than you have; the question is if the change should be made at all. Here's a thought that just occurred to me: What if we have 3.0.6 keep writing hist files in the old format, but treat a finish time less than the start time as the new format? Then 3.0.6 and 3.1.6 will be able to exchange history files with each other. A transition phase like that seems worthwhile to me. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com