From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9714 invoked from network); 16 Jun 1999 22:00:30 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Jun 1999 22:00:30 -0000 Received: (qmail 8876 invoked by alias); 16 Jun 1999 22:00:11 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6682 Received: (qmail 8867 invoked from network); 16 Jun 1999 22:00:10 -0000 Date: Wed, 16 Jun 1999 14:59:48 -0700 (PDT) From: Wayne Davison To: Bart Schaefer cc: zsh-workers@sunsite.auc.dk Subject: Re: history related suggestions (plus bug reports) In-Reply-To: <990616081913.ZM29592@candle.brasslantern.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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? Or maybe you're thinking that !-history references wouldn't find the old history lines? The line would be visited by default for history movement and searching, though. I haven't yet been convinced that we should go this route, but with some extra changes, this might be a workable solution. 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. This would allow the user to execute old sequences of commands that were loaded as foreign, and even new sequences of foreign commands that were loaded via SHARE_HISTORY (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. However, if others don't think that this would be a bad thing, I could be swayed on the subject. Alternately, we could have the history command only use the new '*'-tagging if SHARE_HISTORY is enabled. > } I'm more likely to recall it than one in my saved history and !1 is > } less typing than !200. Since the history line numbers don't wrap around like you thought, I don't think this is possible. Personally, I find using "!cmd" and the various search commands (especially incremental search backward) easier than using absolute history numbers, but YMMV. > As long as we're on the subject ... the HIST_EXPIRE_DUPS_FIRST > option has some bad side-effects involving the {accept-and,} > infer-next-history zle commands. Yes, that is what I consider an expected consequence: you are specifying a preference for maximizing the number of unique commands rather than maintaining the most recent command sequences. However, the current implementation could be made better with an improvement that I've been meaning to package up for public consumption. Here's the issue: There is a problem with HIST_EXPIRE_DUPS_FIRST where it can become identical to HIST_IGNORE_ALL_DUPS once the internal history fills up with unique commands (at this point, non-unique commands would get immediately dropped). 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. Index: Src/hist.c --- zsh-3.1.5-pws-22/Src/hist.c Mon Jun 14 09:14:31 1999 +++ ./Src/hist.c Wed Jun 16 14:22:38 1999 @@ -888,9 +888,14 @@ else { he = hist_ring->down; if (isset(HISTEXPIREDUPSFIRST) && !(he->flags & HIST_DUP)) { + int max_unique_ct = getiparam("SAVEHIST"); do { + if (max_unique_ct-- <= 0) { + he = hist_ring->down; + break; + } he = he->down; - } while (he != hist_ring->down && !(he->flags & HIST_DUP)) ; + } while (he != hist_ring->down && !(he->flags & HIST_DUP)); if (he != hist_ring->down) { he->up->down = he->down; he->down->up = he->up; If people like this change, I'll go ahead and document it. While we're on the subject of adversely affecting infer-next-history, it is good to remember that using SHARE_HISTORY also has an adverse effect when a new shell is started (since the shell treats the entire mass of saved history as uniform when it is read in, even when the lines originally came from multiple shells). 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, though (but someone who uses infer-next-history more than me may well disagree). If we add this, I have no idea how to make the history command display which lines are grouped together for recall with infer-next-history. ..wayne..