Re: PATCH: history improvements for 3.1.5-pws-17 and 3.0.6-pre-2

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>]

I've applied both the other history patches, and it does exactly what I was
hoping, thanks.

Wayne Davison wrote:
> I'm torn on the issue, because sometimes I want to up-arrow through
> the total history, and sometimes I just want to press ^P and run the
> last command that I ran in this window, no exceptions.

You can setopt histverify and edit the line produced by !!, of course, but
I don't claim that's a perfect solution.

> I'd be interested in suggestions for how we can let the user choose
> between local-history and full-history movement.  Perhaps a toggle
> command?  Or a bindable prefix (so I can have ^P ignore shared
> history, and Up-Arrow include it)?  I like this idea.

You mean something like a toggle, either for the next command only or
permanently?  That might work.  You could then have a zle widget

up-line-or-local-history {
  zle toggle-local-history
  zle up-line-or-history
}

if it works on the next command, or

up-line-or-local-history {
  integer savnum=$NUMERIC
  NUMERIC=1
  zle toggle-local-history
  NUMERIC=$savnum
  zle up-line-or-history
  NUMERIC=0
  zle toggle-local-history
}

if it was a permanent state change.  Hmmm, it might be a good idea to
make `zle widget num' override the value of $NUMERIC with num when calling
a widget.

> > I'd like to suggest that any zle reference to the history [...]
> > causes the newly imported stuff to be visible.
> 
> I think that some zle commands, such as accept_and_infer_next_
> history, should remain unaffected by foreign commands.

OK, I hadn't thought about that one, it was really only up/down commands
that crossed my mind.

> I think you've misinterpreted what's going on.  The current code
> waits until the command _finishes_ before adding it to the history
> file.  I did this because the extended_history format contains the
> finish time of the command.  I also don't like this delay in adding
> the command, though, so I think we add the command after it is typed,
> and just live with the fact that all the finish times will be the
> same as the start times when using incremental_append_history (which
> is used by shared_history).

I don't quite understand how that was making the difference.  The command
was finishing in one window; all my comments about how the history list got
retrieved in the other window presupposed I hadn't done anything else in
the first window, i.e. its command was definitely saved.  Is the point
that reading the foreign history happened at the same time as writing the
local one, so that the line saved from the first window was getting read
later than I expected in the second?  though I don't quite believe that,
looking at the old code.

Perhaps on the question of incremental_append_history/append_history it
would be a good idea to ask on the users list if they like the idea of the
existing option being altered.  The effect is different, even if you aren't
using shared history, however.

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