Re: Foreign Commands Not Appearing in 'history' Array When 'sharehistory' Option is Enabled Until a Command is Entered

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Nov 23, 2024 at 11:41 PM Roman Perepelitsa
<roman.perepelitsa@xxxxxxxxx> wrote:
>
> Expected:
>
>     adam% : 2
>     : 2
>
> Actual:
>
>     adam% : 2
>     : 1
>
> We can see that `zle up-history` sees the last history event, which
> was written by Terminal 2, but `history` does not have it.

Change the prompt to display %h (history event number) and change the
test function to

  function test-history() {
      zle up-history
      zle -M -- "$HISTNO $#history ${history[${#history}]}"
  }

This will demonstrate what's happening:  The event shared from
Terminal 2 is being placed in the "current event" slot ($HISTNO) which
is not committed to the full history until a non-empty command is
executed.  I believe this in turn is because the test-history widget
is (by program logic) being executed "during editing of the current
event" and consequently that edit is considered unfinished.

I don't have availability to chase this any further any time soon, nor
any clues as to how difficult it would be to alter this behavior in
the face of shared history.  The logic about when to commit the
"current event" is pretty deeply ingrained.