Re: Upcoming: handy history extensions

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>]

Wayne Davison wrote:
> HIST_SAVE_NO_DUPS
> HIST_FIND_NO_DUPS
> HIST_EXPIRE_DUPS_FIRST
> HIST_IGNORE_ALL_DUPS
> INCREMENTAL_APPEND_HISTORY
> SHARE_HISTORY

I like these, but it does show (again) that the option-setting mechanism is
a bit old-fashioned, i.e. we really need a simpler way of telling the shell
what to do with duplicates than five boolean options.  Maybe we just need
some easy front end.  SHARE_HISTORY should presumably be turned on in ksh
compatibility mode.  Maybe we should even think in the longer term about
making interactive history a loadable module.

Getting the lexer to reparse history lines is probably non-trivial.  It
wouldn't be as bad as get_comp_string in zle_tricky.c, since all the lines
are complete with no current context.  However, reassembling the line is
probably a lot of work.  Perhaps the best bet would be to use the same
mechanism as happens when the line is first read, i.e. the lexer calls all
the appropriate history functions directly.

> I'm also wondering if we should be using a better string-hash
> function than the one in hasher().  I haven't yet analyzed the
> distribution of nodes within a hash table, but I was thinking that a
> generic CRC function might give us better results.  Also, is there
> any interest in rounding up the history table sizes to the nearest
> prime number?  DBZ has a simple (but not terribly efficient)
> algorithm for this, for instance.

I can't remember anybody ever thinking about this, so it's quite possible
it could do with changing.

> Another issue is history-file locking.  I think we want to lock the
> file when doing incremental updating (especially since re-writing
> now occurs much more frequently).  I'm not familiar with how to get
> metaconfig to look for the current machine's file-locking functions,
> though.  Anyone want to help me out?  If not, I'll look it up later.

It doesn't look like there is any generic autoconf support for this.  Some
mail package might have some autoconf code for checking, possibly emacs.
However, checking for fcntl/F_SETLKW etc., lockf/F_LOCK etc., flock/LOCK_SH
etc. should be straightforward; it's probably safest to use AC_TRY_COMPILE
to see if the expected set of flags is present, and define, say,
HAVE_LOCK_FCNTL, HAVE_LOCK_LOCKF or HAVE_LOCK_FLOCK.  I could potentially
write this.  Then there's the whole Lockdaemon From Hell saga, which we had
better just forget about.

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy