Re: history related suggestions (plus bug reports)

[Wayne Davison <wayne@xxxxxxxxx>]

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..