Undo works differently when buffer is populated by job_start() about vim

[lifepillar]

According to :help undojoin, calling getchar() should start a new change. That does not seem to be the case if the code using getchar() is in a callback.

[zeertzjq]

According to :help undojoin, calling getchar() should start a new change. That does not seem to be the case if the code using getchar() is in a callback.

I don't think that's the case. It just recommends that you use :undojoin before calling getchar().

[chrisbra]

I agree with @zeertzjq reading of the help.

[lifepillar]

I beg to disagree. The help describes a case where undojoin is necessary to merge two changes with a getchar() in between exactly because

the next key press will start a new change

In fact, that is what happens:

vim9script

def Foo()
  normal aX
  getchar()
  normal aY
  undo
enddef

Foo()

X remains in the buffer after the undo. But if the function is used as a callback, it behaves as if undojoin has been added. That is, in the following script:

vim9script

def Foo()
  normal aX
  getchar()
  normal aY
  undo
enddef

job_start(['ls'], {'close_cb': (_) => Foo()})

Foo() behaves the same as in:

vim9script

def Foo()
  normal aX
  getchar()
  undojoin
  normal aY
  undo
enddef

Foo()

I would like the function invoked as a job_start()'s callback to behave the same as if invoked directly.

[Edited for clarity]

[lifepillar]

A workaround for this issue is to force a new change:

def Foo()
  normal aX
  getchar()
  execute "normal" "i\<c-g>u"
  normal aY
  undo
enddef

Similarly, my original example is fixed by adding execute "normal" "i\<c-g>u" before (or after) getcharstr().