Regression bug with `nvim_buf_set_lines` on Neovim nightly

[wojciech-kulik]

Regression bug with `nvim_buf_set_lines` on Neovim nightly

[clason]

In particular, provide min.lua and test.file so we can run nvim --clean -u min.lua test.file and reproduce the issue (if necessary, with add debug output).

[echasnovski]

I've bisected it to 0081549 which was part of #24824.
cc @bfredl

[bfredl]

The instructions above do not uniquely identify a situation. I could easily expand that script myself into some complete reproduction script, but so in multiple different ways. Depending on the missing details, the current behavior might or might not actually be the desired one (a change from 0.9.5 is not enough to identify a regression).

[bfredl]

Trivially: OTHER_BUFFER_ID is not defined. and it is not clear at all what that should refer to in your step 2 and 4 respectively.

It is better to just provide a complete script directly, instead of having us guess stuff, to avoid any misunderstanding.

[wojciech-kulik]

Here is the code to reproduce it... the buffer with the content is scrolled to top after setting lines. When you focus it again, the expected scroll position is restored.

local lines = {}
for i = 1, 100 do
  lines[i] = tostring(i)
end

vim.cmd(":new")
local newBuf = vim.api.nvim_get_current_buf()

vim.api.nvim_buf_set_lines(newBuf, 0, -1, false, lines)
vim.cmd(":50")

vim.cmd("vnew")
vim.api.nvim_buf_set_lines(newBuf, 0, -1, false, lines)

[wojciech-kulik]

Workaround:

for i, line in ipairs(lines) do
  vim.api.nvim_buf_set_lines(M.bufnr, i - 1, i, false, { line })
end

[wojciech-kulik]

@bfredl you didn't provide information on what is exactly missing. Reproduction steps have been provided and the video showing the situation is provided, plus you got the specific commit that changes this behavior. I think you have everything you need :).

[pysan3]

@bfredl Could you please take a moment to review this issue as well? Here is the link: #27720

Although my issue may not be identical to the one described here, there is a possibility that they share the same root cause.

I have also included steps to reproduce the issue.

[bfredl]

Thanks, it's clear now.

I cannot reproduce however on master ( 633bf61) with nvim --clean -u path/to/script.lua. Although the behavior you describe sounds like it could happen (for the same reasons as in #27720 (comment) ), am I missing something more?

[wojciech-kulik]

Maybe it's a matter of timing.

When I call :luafile path/to/script.lua after nvim --clean -u path/to/script.lua it's reproducible.

[wojciech-kulik]

Another related issue: #25370