command recall

command recall

[Ray Andrews]

I have:

INC_APPEND_HISTORY
SHARE_HISTORY

... set and my up arrow is:
bindkey "\e[A" history-beginning-search-backward

When I type '$ history' what happens in one terminal is immediately 
shown in the history list in any other terminal as I'd expect, however 
the up arrow key does not show the most recent global command.  If I 
type 'history' in some terminal and then hit the up arrow, it is now the 
most recent command but not otherwise.  Can I get up arrow to be up to 
the moment the same way that 'history' is? Actually it would be cool to 
be able to quickly toggle that on or off, so I could have a terminal 
isolated from global history or not as I choose. I'd expect 
'history-beginning-search-backward' to obey the intent of the two 
options set above.

Re: command recall

[Lawrence Velázquez]

> On Feb 6, 2021, at 11:36 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> 
> I have:
> 
> INC_APPEND_HISTORY
> SHARE_HISTORY

There is no need to enable both of these; SHARE_HISTORY alone is
sufficient. The zshoptions(1) man page makes this pretty clear.

> ... set and my up arrow is:
> bindkey "\e[A" history-beginning-search-backward
> 
> When I type '$ history' what happens in one terminal is immediately shown in the history list in any other terminal as I'd expect, however the up arrow key does not show the most recent global command.  If I type 'history' in some terminal and then hit the up arrow, it is now the most recent command but not otherwise.  Can I get up arrow to be up to the moment the same way that 'history' is?

You don't have to actually run a command; you can just hit Return
at an empty prompt.

vq

Re: command recall

[Lawrence Velázquez]

> On Feb 6, 2021, at 12:10 PM, Lawrence Velázquez <vq@larryv.me> wrote:
> 
>> On Feb 6, 2021, at 11:36 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> 
>> ... set and my up arrow is:
>> bindkey "\e[A" history-beginning-search-backward

I suppose you could write your own widget that updates the internal
history first. Someone else would have to provide guidance on that.

vq

Re: command recall

[Bart Schaefer]

On Sat, Feb 6, 2021 at 9:22 AM Lawrence Velázquez <vq@larryv.me> wrote:
>
> > On Feb 6, 2021, at 12:10 PM, Lawrence Velázquez <vq@larryv.me> wrote:
> >
> >> On Feb 6, 2021, at 11:36 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> >>
> >> ... set and my up arrow is:
> >> bindkey "\e[A" history-beginning-search-backward
>
> I suppose you could write your own widget that updates the internal
> history first. Someone else would have to provide guidance on that.

The issue here is that when sitting at a prompt, zsh is (usually)
doing literally nothing.  It can't discover that the history file has
changed until you unblock it by doing something, and it doesn't update
the shared history until the current local history is ready to be
written.

You might be able to write a zle -F handler that interrupts ZLE if the
history file changes, causing the changed lines to be read (and a new
prompt printed).  If that works, the next issue would be preventing
terminal A from scrolling every time you do something in terminal B.

Re: command recall

[Ray Andrews]

On 2021-02-06 2:08 p.m., Bart Schaefer wrote:
>
> The issue here is that when sitting at a prompt, zsh is (usually)
> doing literally nothing.  It can't discover that the history file has
> changed until you unblock it by doing something, and it doesn't update
> the shared history until the current local history is ready to be
> written.
You know, when one understands the logic of the thing, the problem isn't 
even a problem
anymore.  Still, hitting the up arrow is doing something is it not? 
Hitting it the second time
updates fine.  '$ history' is up to the second so why couldn't the up 
arrow check the same
up to date history list before giving you a line rather than after? 
Ultimate small issue tho.

Re: command recall

[Bart Schaefer]

On Sat, Feb 6, 2021 at 3:12 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2021-02-06 2:08 p.m., Bart Schaefer wrote:
> >
> > ... it doesn't update
> > the shared history until the current local history is ready to be
> > written.
> Still, hitting the up arrow is doing something is it not?

To go into too much detail, there's an unsaved dummy history entry at
the bottom of the internal list, to represent the command the prompt
is waiting for, and the history file isn't consulted until that dummy
entry is either discarded (accept-line on empty buffer) or ready to be
merged with the file contents.  There are all sorts of reasons for
this, including being able to have a stable numbering scheme (keys in
the $history hash table) during computation of zle widgets.

>  '$ history' is up to the second

That's because the order of operations is
1) You accept-line, so the pinocchio entry is ready to become a real boy
2) Consequently, the history gets merged
3) The "history" command executes

Re: command recall

[Ray Andrews]

On 2021-02-07 8:56 a.m., Bart Schaefer wrote:

> ... There are all sorts of reasons for
> this, including being able to have a stable numbering scheme (keys in
> the $history hash table) during computation of zle widgets.
I wondered how that worked.  With half a dozen open terminals, each of 
them accepting
commands at various times, it's quite cool how they all end up in 
chronological order when
merged.  I've tried all sorts of ways to break that but it refuses to be 
fooled.
>
> That's because the order of operations is
> 1) You accept-line, so the pinocchio entry is ready to become a real boy
> 2) Consequently, the history gets merged
> 3) The "history" command executes
This is the tiniest of issues but I was just about to start 
experimenting with making
a widget, which I did once and it worked.  If you had:

....
accept-line
history-beginning-search-backward
....

would that work?  Probably some easy way to force the merge before the 
search, no?
Still it seems intuitive that this should happen anyway.

Re: command recall

[Bart Schaefer]

On Sat, Feb 6, 2021 at 8:37 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Actually it would be cool to
> be able to quickly toggle that on or off, so I could have a terminal
> isolated from global history or not as I choose.

If you zsh "A" has
  setopt incappendhistory
and zsh "B" has
  setopt sharehistory
then A will have only its local history, and B will have the history
from both itself and A.

Re: command recall

[Bart Schaefer]

On Sun, Feb 7, 2021 at 10:10 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> ....
> accept-line
> history-beginning-search-backward
> ....
>
> would that work?

Not that, because accept-line effectively terminates the widget, so
history-beginning-search-backward is never reached.

The following might work; I don't use sharehistory so setting up a
test case is a bit more than I want to get into today:

shared-history-beginning-search-backward() {
   fc -RI
   zle .history-beginning-search-backward "$@"
}
zle -N history-beginning-search-backward \
  shared-history-beginning-search-backward

Re: command recall

[Ray Andrews]

On 2021-02-07 12:42 p.m., Bart Schaefer wrote:
> shared-history-beginning-search-backward() {
>     fc -RI
>     zle .history-beginning-search-backward "$@"
> }
> zle -N history-beginning-search-backward \
>    shared-history-beginning-search-backward
Seems to work fine, thanks.