From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29221 invoked from network); 16 Jun 1999 08:19:51 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Jun 1999 08:19:51 -0000 Received: (qmail 26894 invoked by alias); 16 Jun 1999 08:19:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6655 Received: (qmail 26887 invoked from network); 16 Jun 1999 08:19:23 -0000 From: "Bart Schaefer" Message-Id: <990616081913.ZM29592@candle.brasslantern.com> Date: Wed, 16 Jun 1999 08:19:13 +0000 In-Reply-To: <4FBF540FF16FD1119D9600A0C94B2B51F29E89@napier.logica.co.uk> Comments: In reply to "Kiddle, Oliver" "history related suggestions" (Jun 15, 2:10pm) References: <4FBF540FF16FD1119D9600A0C94B2B51F29E89@napier.logica.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Subject: Re: history related suggestions (plus bug reports) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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. That's probably because the only shells that I frequently start and stop are those to remote systems where I only run a few commands (I tend to stay logged in to a couple of xterms for weeks when using the local console). Nevertheless it would bug me to have to use a different search command to find those. Such a change could also cause confusion for people who are upgrading from 3.0 ("Where'd my history go?!?"). } What I would also like is if these were numbered so that the most } recent one is the same as $HISTSIZE. This would mean that when I first } run zsh, the first command I type would be number 1, not 200. How would you refer in bang-syntax to the commands that precede 1 ? They can't be given negative numbers; !-10 already means ten commands before the current command. } I'm more likely to recall it than one in my saved history and !1 is } less typing than !200. Ideally, what would be nice is if the numbers } of commands between two versions of zsh running at the same time would } correspond but I imagine that it wouldn't be easy to implement and } would cause a few problems. You could accomplish that by completly flushing and reloading the history from the shared file every time that the file changes, starting over at 1 with the numbering each time -- but I think you'd rapidly find that it was more annoying than useful: the number that a command had a moment ago would no longer be the number it has now, so your reference to !4 might get the wrong thing. As long as we're on the subject ... the HIST_EXPIRE_DUPS_FIRST option has some bad side-effects involving the {accept-and,}infer-next-history zle commands. One things start falling out of the middle of the history, it is possible to refer to a command whose logical next no longer exists, so those commands retrieve the wrong thing. On a possibly-related note, "history -r" seems to be broken now: zagzig<7> history 1 setopt | grep hist 3 echo foobar 4 setopt histexpiredupsfirst 5 typeset | grep HIST 6 HISTSIZE=6 zagzig<8> !-3:p typeset | grep HIST zagzig<9> !-2:p history zagzig<10> hh fc: no events in that range zagzig<11> alias hh hh='history -r -$HISTSIZE | more' zagzig<12> echo $HISTSIZE 6 zagzig<13> exit (Now start over) zagzig<1> hh fc: bad history number: 1 zagzig<2> hh fc: bad history number: 1 zagzig<2> echo this is a test this is a test zagzig<3> hh fc: no events in that range zagzig<4> 3.0.6-pre-4 doesn't suffer from this problem, so it must have something to do with the new history extensions. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com