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