From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27316 invoked from network); 10 May 2001 07:04:48 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 May 2001 07:04:48 -0000 Received: (qmail 17645 invoked by alias); 10 May 2001 07:04:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14292 Received: (qmail 17625 invoked from network); 10 May 2001 07:04:41 -0000 From: "Bart Schaefer" Message-Id: <1010510070413.ZM14821@candle.brasslantern.com> Date: Thu, 10 May 2001 07:04:13 +0000 References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Re: Proposed history improvements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 9, 3:45pm, Wayne Davison wrote: } } 1. I have gotten in the habit of prefixing certain commands with a space } that I don't want cluttering up my history. I've never used hist_ignore_space because I frequently copy-and-paste commands and I dislike having to be careful about whether I grab any leading whitespace in the process. I'd much rather decide after the fact that I didn't want that command put into the history; for example, I'd expunge all commands involving typographical errors as soon as I'd had a chance to retrieve them and fix the error, so that correct commands are never pushed out of the history file by mistaken ones. } My change makes an ignored command stick around just until the next } command is typed. This is a step in the right direction, at least. } Do you think something like this should require a separate option? No, I don't think it needs an option ... I think it should have worked like this all along. On May 10, 4:36am, Zefram wrote: } Subject: Re: Proposed history improvements } } Wayne Davison wrote: } >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. [...] 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. [...] } Or probably a better way would be to have a virtual associative array } giving this importance number for each history element [...] I agree that the proposed "deprecate" options are getting a bit complex, and that some sort of shell-code solution seems preferable (this assoc array suggestion would even let me implement deprecate-ex-post-facto). With the assoc, we could avoid calling a function every time the history is modified, and simply fix it up by assigning directly to the parameter from precmd, which is a nice safe time and place to do it with respect to other commands the shell is executing. We'd need a better way to get at the current and previous event numbers, though. (Have a look at the hack I did in zsh-workers/10996.) } Actually almost the whole history mechanism *could* be moved out of } the C [a]nd into shell code. This would take quite a lot of work; emulating linked lists and rings in shell code is messy at best. (13.5% of all zsh options are related to history. 14.3% if Wayne goes ahead with committing HIST_IMMEDIATE_DROP, on which I have no comment except to say I think it's extraneous.) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net