From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25414 invoked from network); 10 May 2001 03:36:53 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 May 2001 03:36:53 -0000 Received: (qmail 14264 invoked by alias); 10 May 2001 03:36:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14289 Received: (qmail 14252 invoked from network); 10 May 2001 03:36:45 -0000 Subject: Re: Proposed history improvements In-Reply-To: from Wayne Davison at "May 9, 2001 03:45:29 pm" To: Wayne Davison Date: Thu, 10 May 2001 04:36:44 +0100 (BST) CC: Zsh Workers X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Wayne Davison wrote: > My change makes an ignored command stick around >just until the next command is typed. Nice. > Do you >think something like this should require a separate option? Probably, but I don't see a problem with the option being on by default. >2. I thought it would be cool if I could hint to the history system >about which lines I consider more important. With HIST_DEPRECATE_SPACE ... This bit is getting too complicated. Instead of having multiple competing options (HIST_DEPRECATE_SPACE and HIST_EXPIRE_DUPS_FIRST -- where's HIST_DEPRECATE_DUPS for the opposite priority ordering?), let's have some configurable shell code to decide how important each history entry is. We can have a shell function that gets called whenever a line is added to the history, which gets to reply a number saying how important the line is. The effect of both HIST_DEPRECATE_SPACE and HIST_EXPIRE_DUPS_FIRST being on can then be achieved by function histimportance { if [[ -n "${(k)history[(r)$1]}" ]]; then REPLY=1 elif [[ "$1" == " "* ]]; then REPLY=2 else REPLY=3 fi } Or probably a better way would be to have a virtual associative array giving this importance number for each history element, initialised according to the existing options, and have a "histadded" function that has the option to change this number for the current event or in fact for any previous event (allowing duplicates to be expired oldest-first instead of the newest-first that the above code does). Other history stuff that could similarly be moved to shell code: deciding whether a history line is to be stored at all (say, the "histadded" function returns non-zero to say "don't add this to the history"); deciding whether a history line is to be saved in the history file (another array, paralleling the `importance' one described above, or an overloaded meaning for the importance array); possibly the history file saving itself. Actually almost the whole history mechanism *could* be moved out of the C nd into shell code. -zefram