history related suggestions

history related suggestions

[Kiddle, Oliver]

I've finally got around to trying out Wayne's recent history extensions (see
msgs 6218, 6236 and 6255) and have a few suggestions.

I'm not convinced by the zle set-local-history system for toggling between
local and shared history. I (and I would think most people) will bind one
set of keys to shared history operations and another set to local ones
rather than binding a key to toggle the history mode. With argument handling
hopefully being added to zle widgets (which I think is a great idea), I
think it would be better to ditch set-local-history and add an option to
each of the history related widgets specifying whether to use shared or
local history. Along with this, I would suggest that parameter expansion be
done on the zle widget arguments each time the widget is run. This would
allow users to do:
bindkey '^[[A' up-line-or-history '$history_toggle'
and then change the $history_toggle variable to select between local and
shared history.

My second suggestion is that the history items imported when zsh first runs
(if SAVEHIST is set) should be marked as foreign.

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. 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.

Oliver Kiddle

Re: history related suggestions

[Peter Stephenson]

"Kiddle, Oliver" wrote:
> I'm not convinced by the zle set-local-history system for toggling between
> local and shared history. I (and I would think most people) will bind one
> set of keys to shared history operations and another set to local ones
> rather than binding a key to toggle the history mode.

You're supposed to use a widget function rather than bind it directly.
(What's happened to the manual entry for set-local-history in the zle
documentation?  It doesn't seem to say anywhere how it works.)

this-with-local-history() {
  local savnum=$NUMERIC
  NUMERIC=1
  zle set-local-history
  NUMERIC=$savnum
  zle the-normal-this-command
  NUMERIC=0
  zle set-local-history
}
zle -N this-with-local-history
bindkey '...' this-with-local-history

(this will all become smoother when argument handling becomes standardised
anyway).

> With argument handling
> hopefully being added to zle widgets (which I think is a great idea), I
> think it would be better to ditch set-local-history and add an option to
> each of the history related widgets specifying whether to use shared or
> local history.

It might be a nice idea to add this.

> Along with this, I would suggest that parameter expansion be
> done on the zle widget arguments each time the widget is run. This would
> allow users to do:
> bindkey '^[[A' up-line-or-history '$history_toggle'
> and then change the $history_toggle variable to select between local and
> shared history.

That sort of thing should certainly be done inside functions.

up-line-or-history-switch() {
  zle up-line-or-history $history_toggle
}
zle -N up-line-or-history-switch
bindkey '^[[A' up-line-or-history-switch

Extra levels of expansion tend to make things a bit of a mess, and in my
experience you always get to the point where you need the extra flexibility
of a function anyway.  (Cf. S. Wischnowsky, Collected New Completion
Mailings, Zsh Workers Mailing List 1999, passim.)

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: history related suggestions (plus bug reports)

[Bart Schaefer]

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

PATCH: pws-22: history -r fix

[Wayne Davison]

On Wed, 16 Jun 1999, Bart Schaefer wrote:
> On a possibly-related note, "history -r" seems to be broken now

Yes, the start-of-loop check was wrong.  Here's a patch:

Index: Src/builtin.c
--- zsh-3.1.5-pws-22/Src/builtin.c	Mon Jun 14 09:14:30 1999
+++ ./Src/builtin.c	Wed Jun 16 13:37:17 1999
@@ -1349,7 +1349,7 @@
 	fclistdone = 1;
 
     ent = gethistent(first, first < last? GETHIST_DOWNWARD : GETHIST_UPWARD);
-    if (!ent || ent->histnum < first || ent->histnum > last) {
+    if (!ent || (first < last? ent->histnum > last : ent->histnum < last)) {
 	if (first == last)
 	    zwarnnam("fc", "no such event: %d", NULL, first);
 	else

..wayne..

Re: history related suggestions (plus bug reports)

[Wayne Davison]

On Wed, 16 Jun 1999, Bart Schaefer wrote:
> 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.

Do you have foreign history toggled off?  Or maybe you're thinking
that !-history references wouldn't find the old history lines?  The
line would be visited by default for history movement and searching,
though.  I haven't yet been convinced that we should go this route,
but with some extra changes, this might be a workable solution.

One thing that occurred to me was that the infer-next-history function
should really find a line in the same local/foreign category as the
line we just used, rather than only using local history lines.  This
would allow the user to execute old sequences of commands that were
loaded as foreign, and even new sequences of foreign commands that
were loaded via SHARE_HISTORY (though it can get weird if you're
reading lines from more than one foreign shell).

Also, I have been hesitant to have the default behavior of the history
command display the old history lines tagged with '*'s (indicating
they are foreign) since I figured that it was less of a compatibility
change if this new marking only occurs if you choose to use the
SHARE_HISTORY option.  However, if others don't think that this would
be a bad thing, I could be swayed on the subject.  Alternately, we
could have the history command only use the new '*'-tagging if
SHARE_HISTORY is enabled.

> } I'm more likely to recall it than one in my saved history and !1 is
> } less typing than !200.

Since the history line numbers don't wrap around like you thought, I
don't think this is possible.

Personally, I find using "!cmd" and the various search commands
(especially incremental search backward) easier than using absolute
history numbers, but YMMV.

> 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.

Yes, that is what I consider an expected consequence:  you are
specifying a preference for maximizing the number of unique commands
rather than maintaining the most recent command sequences.  However,
the current implementation could be made better with an improvement
that I've been meaning to package up for public consumption.  Here's
the issue:

There is a problem with HIST_EXPIRE_DUPS_FIRST where it can become
identical to HIST_IGNORE_ALL_DUPS once the internal history fills up
with unique commands (at this point, non-unique commands would get
immediately dropped).

The following patch changes this to limit the size of the unique
history commands at the start of the internal history buffer to the
$SAVEHIST value.  This allows you to set HISTSIZE to a larger number
than SAVEHIST, and thus get some slack space for keeping the latest
sequences of commands.

Index: Src/hist.c
--- zsh-3.1.5-pws-22/Src/hist.c	Mon Jun 14 09:14:31 1999
+++ ./Src/hist.c	Wed Jun 16 14:22:38 1999
@@ -888,9 +888,14 @@
     else {
 	he = hist_ring->down;
 	if (isset(HISTEXPIREDUPSFIRST) && !(he->flags & HIST_DUP)) {
+	    int max_unique_ct = getiparam("SAVEHIST");
 	    do {
+		if (max_unique_ct-- <= 0) {
+		    he = hist_ring->down;
+		    break;
+		}
 		he = he->down;
-	    } while (he != hist_ring->down && !(he->flags & HIST_DUP)) ;
+	    } while (he != hist_ring->down && !(he->flags & HIST_DUP));
 	    if (he != hist_ring->down) {
 		he->up->down = he->down;
 		he->down->up = he->up;

If people like this change, I'll go ahead and document it.

While we're on the subject of adversely affecting infer-next-history,
it is good to remember that using SHARE_HISTORY also has an adverse
effect when a new shell is started (since the shell treats the entire
mass of saved history as uniform when it is read in, even when the
lines originally came from multiple shells).  It would be possible to
enhance the history-file format to save the pid of the process that
wrote the line, and thus allow us to make history inferences using the
next line from the same pid.  I'm not sure this is really needed,
though (but someone who uses infer-next-history more than me may well
disagree).  If we add this, I have no idea how to make the history
command display which lines are grouped together for recall with
infer-next-history.

..wayne..

Re: history related suggestions (plus bug reports)

[Bart Schaefer]

On Jun 16,  2:59pm, Wayne Davison wrote:
} Subject: Re: history related suggestions (plus bug reports)
}
} On Wed, 16 Jun 1999, Bart Schaefer wrote:
} > 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.
} 
} Do you have foreign history toggled off?

Yes.

} One thing that occurred to me was that the infer-next-history function
} should really find a line in the same local/foreign category as the
} line we just used, rather than only using local history lines.

I think that would just be confusing.  Perhaps better would be if it
searched the local or foreign history based on the state of the toggle.
However, as you point out:

} (though it can get weird if you're reading lines from more than one
} foreign shell).

} Also, I have been hesitant to have the default behavior of the history
} command display the old history lines tagged with '*'s (indicating
} they are foreign) since I figured that it was less of a compatibility
} change if this new marking only occurs if you choose to use the
} SHARE_HISTORY option.

I don't see much problem with this, because it's mostly a display thing.
(I can't think of any reason, at least not before expire-dups-first came
along, to attempt to parse the output of fc or history.)

} It would be possible to
} enhance the history-file format to save the pid of the process that
} wrote the line, and thus allow us to make history inferences using the
} next line from the same pid.  I'm not sure this is really needed,

I think it's probably overkill, and it's also not reliable.  Process IDs
are hardly unique, especially when NFS gets involved.  Maybe I'm being
strange yet again, but I prefer predictable mistakes to unpredictable,
even if the predictable ones happen a bit more often. 

} The following patch changes this to limit the size of the unique
} history commands at the start of the internal history buffer to the
} $SAVEHIST value.  This allows you to set HISTSIZE to a larger number
} than SAVEHIST, and thus get some slack space for keeping the latest
} sequences of commands.

Seems fine to me.  BTW, before this shared history thing came along, there
was never any good reason to make SAVEHSIT bigger than HISTSIZE.  Has that
changed?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com