Re: history related suggestions

Re: history related suggestions

[Kiddle, Oliver]

Peter Stephenson wrote:

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

Fair enough if it's hard to implement but my thinking was that it would
allow a lot of problems to be solved more succinctly than by using a
function. 

Bart Schaefer wrote:

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

They would be numbered from $HISTSIZE downwards so for example, if you have
HISTSIZE=500 and SAVEHIST=100, they would be numbered from !401 to !500. I
always thought it would be better if the history numbers wrapped back to 1
once they reached $HISTSIZE rather than carrying on into the thousands. What
currently happens if $SAVEHIST is greater than $HISTSIZE?

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

Yup, that would be nasty. I mostly look at prompts back in my buffer for
history numbers rather than the output of fc. Having thought about it a bit
more, it would probably be quite hard to implement properly as shell's would
have to reserve the history number once they printed a prompt so forget the
suggestion.

Cheers

Oliver Kiddle

Re: history related suggestions

[Sven Wischnowsky]

Kiddle, Oliver wrote:

> > 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
> 
> Fair enough if it's hard to implement but my thinking was that it would
> allow a lot of problems to be solved more succinctly than by using a
> function. 

It's easy to implement (and indeed my suggestion for aliases does that 
-- although I didn't really like it when I wrote it). The problem this 
always leads to is quoting: if you want to pass the string `$foo' to a 
widget you don't want the shell to expand it.

Anyway, we could add a automatic-autoloading mechanism for widgets,
too, making defining them simple.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

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