From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15917 invoked from network); 5 May 1999 09:25:11 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 May 1999 09:25:11 -0000 Received: (qmail 19190 invoked by alias); 5 May 1999 08:35:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6222 Received: (qmail 19180 invoked from network); 5 May 1999 08:35:38 -0000 Message-Id: <9905050811.AA13411@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: Upcoming: handy history extensions In-Reply-To: "Wayne Davison"'s message of "Tue, 04 May 1999 12:42:14 DFT." <199905041942.MAA11235@bebop.clari.net> Date: Wed, 05 May 1999 10:11:10 +0200 From: Peter Stephenson 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 Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy