From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15687 invoked from network); 17 Jun 1999 07:21:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Jun 1999 07:21:42 -0000 Received: (qmail 21060 invoked by alias); 17 Jun 1999 07:21:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6684 Received: (qmail 21049 invoked from network); 17 Jun 1999 07:21:17 -0000 From: "Bart Schaefer" Message-Id: <990617063336.ZM3327@candle.brasslantern.com> Date: Thu, 17 Jun 1999 06:33:36 +0000 In-Reply-To: Comments: In reply to Wayne Davison "Re: history related suggestions (plus bug reports)" (Jun 16, 2:59pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Wayne Davison Subject: Re: history related suggestions (plus bug reports) Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 16, 2:59pm, Wayne Davison wrote: } Subject: Re: history related suggestions (plus bug reports) } } On Wed, 16 Jun 1999, Bart Schaefer wrote: } > On Jun 15, 2:10pm, Kiddle, Oliver wrote: } > } Subject: history related suggestions } > } } > } My second suggestion is that the history items imported when zsh first } > } runs (if SAVEHIST is set) should be marked as foreign. } > } > Oh, I don't like that idea at all. Maybe I'm just funny, but a } > lot of the time when I start a shell the first thing I do is run a } > command searched from the history of my last session. } } Do you have foreign history toggled off? Yes. } One thing that occurred to me was that the infer-next-history function } should really find a line in the same local/foreign category as the } line we just used, rather than only using local history lines. I think that would just be confusing. Perhaps better would be if it searched the local or foreign history based on the state of the toggle. However, as you point out: } (though it can get weird if you're reading lines from more than one } foreign shell). } Also, I have been hesitant to have the default behavior of the history } command display the old history lines tagged with '*'s (indicating } they are foreign) since I figured that it was less of a compatibility } change if this new marking only occurs if you choose to use the } SHARE_HISTORY option. I don't see much problem with this, because it's mostly a display thing. (I can't think of any reason, at least not before expire-dups-first came along, to attempt to parse the output of fc or history.) } It would be possible to } enhance the history-file format to save the pid of the process that } wrote the line, and thus allow us to make history inferences using the } next line from the same pid. I'm not sure this is really needed, I think it's probably overkill, and it's also not reliable. Process IDs are hardly unique, especially when NFS gets involved. Maybe I'm being strange yet again, but I prefer predictable mistakes to unpredictable, even if the predictable ones happen a bit more often. } The following patch changes this to limit the size of the unique } history commands at the start of the internal history buffer to the } $SAVEHIST value. This allows you to set HISTSIZE to a larger number } than SAVEHIST, and thus get some slack space for keeping the latest } sequences of commands. Seems fine to me. BTW, before this shared history thing came along, there was never any good reason to make SAVEHSIT bigger than HISTSIZE. Has that changed? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com