Re: history related suggestions (plus bug reports)

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

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