Re: history related suggestions (plus bug reports)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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