on_bytes args of nvim_buf_attach are different when using o and A<Enter>

[lucario387]

Problem

This is possibly the same as #25822

Using o, the args passed to on_bytes of nvim_buf_attach is different from when using A<Enter>

Steps to reproduce

• Have a test.lua file as such

vim.api.nvim_create_autocmd("BufEnter", {
  callback = function(args)
    vim.api.nvim_buf_attach(args.buf, true, {
      on_bytes = function(_, _, _, start_row, _, _, old_end_row, _, _, new_end_row, _, _)
        print(start_row, old_end_row, new_end_row)
      end
    })
  end
})

• nvim --clean -u test.lua test.foo and do o. We get 1 0 1
• nvim --clean -u test.lua test.foo and do A<Enter>. We get 0 0 1

Expected behavior

They should both be 0 0 1, or be more consistent.

Neovim version (nvim -v)

NVIM v0.10.0-dev-43b0e2752

Vim (not Nvim) behaves the same?

unsure

Operating system/version

Linux 6.6.1

Terminal name/version

kitty 0.31.0

$TERM environment variable

xterm-kitty

Installation

Build from source

[lucario387]

This is also why #25822 was incorrect, I'd assume.

As on_bytes of foldexpr was relying on nvim_buf_attach's on_bytes to return the correct start row, old row and new row, but pressing O means the start row is the same as the new index, meaning the row range is one-off from the correct one. This can also be confirmed by instead doing A<Enter>, and the foldcolumn is correctly updated

[tomtomjhj]

seems to be fixed by #26364.