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

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Mon, Nov 25, 2024 at 9:12 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> 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.

Another consequence of this is
https://www.zsh.org/mla/workers/2021/msg01087.html

-- 
Mikael Magnusson