REPL append line is triggering events for other buffers

[Rónán Carrigan]

Debug adapter definition and debug configuration

Using nvim-dap-python

Debug adapter version

1.5.1

Steps to Reproduce

1. Create a test file test.py

print("hello world")

2. Source this code

local bufnr = vim.fn.bufnr("test.py")

vim.api.nvim_buf_attach(bufnr, false, {
  on_lines = function (...)
    print("changed")
  end,
  utf_sizes = true,
})

3. Open the REPL
4. Use launch file config to run script

Expected Result

REPL renders correctly and nothing else

Actual Result

The event is triggered for the test.py buffer due to the REPL change. If you are using pyright LSP you will see an error because of the lsp change handling

Error executing vim.schedule lua callback: Vim:Error executing lua callback: /usr/share/nvim/runtime/lua/vim/lsp.lua:411: Index out of bounds
stack traceback:
        [C]: in function 'nvim_buf_get_lines'
        /usr/share/nvim/runtime/lua/vim/lsp.lua:411: in function 'incremental_changes'
        /usr/share/nvim/runtime/lua/vim/lsp.lua:460: in function 'fn'
        /usr/share/nvim/runtime/lua/vim/lsp.lua:164: in function 'for_each_buffer_client'
        /usr/share/nvim/runtime/lua/vim/lsp.lua:1184: in function </usr/share/nvim/runtime/lua/vim/lsp.lua:1176>
        [C]: in function 'appendbufline'
        ...re/nvim/site/pack/packer/start/nvim-dap/lua/dap/repl.lua:293: in function 'append'
        ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:398: in function 'callback'
        ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:604: in function <...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:596>
stack traceback:
        [C]: in function 'appendbufline'
        ...re/nvim/site/pack/packer/start/nvim-dap/lua/dap/repl.lua:293: in function 'append'
        ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:398: in function 'callback'
        ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:604: in function <...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:596>

I've seen a couple of people report weird issues with LSP when using nvim-dap and I'm almost certain this is why.

I think this might be an error in neovim itself but since you're familiar with neovim source I thought I'd post here in case I'm missing something. I'm also struggling to reproduce except with nvim-dap REPL

[Mathias Fußenegger]

I'm not able to reproduce this. For me the changed events don't fire (unless I edit the test.py buffer itself)

Just to be sure:

1. You're opening the REPL via require'dap'.repl.open()?
2. The hello world output appears in the REPL after the error?
3. Does the changed output also fire for you if you type in the REPL?
4. What neovim version are you using? I tried with both 0.6.1 and a recent nightly

[Rónán Carrigan]

Ah OK so it seems to be inconsistent, this morning that file reproduced multiple times but now it's sometimes not. Changing to

print("hello world")
raise Exception

seems to always trigger the issue

1. You're opening the REPL via require'dap'.repl.open()?

Yep I am, not using nvim-dap-ui at all

2. The hello world output appears in the REPL after the error?

Yes the REPL renders everything correctly.

3. Does the changed output also fire for you if you type in the REPL?

No it only happens when in the buffer AFAICT. My best guess as to why is some weirdness going on with the curbuf global in C code which is changed when using appendbufline.

4. What neovim version are you using? I tried with both 0.6.1 and a recent nightly

Using nightly, updated today but has been happening for a while

Here is a quick recording of it happening.
https://user-images.githubusercontent.com/24252670/157513006-73b842b6-9683-4cf5-b930-0138ee6df6bc.mp4

When I have a little time I can put together a minimal init to reproduce for you. It's possible that some other plugin is interfering somehow

[Mathias Fußenegger]

Still can't reproduce it.

Could you give #466 a try? If it fixes it for you it would really point to an issue with appendbufline

[Rónán Carrigan]

Yes that change does work perfectly AFAICT. Strange as they're both setting and using curbuf, but they are handling it differently.

I can try to isolate further and report to neovim repo if there is something to reproduce

[Mathias Fußenegger]

I can try to isolate further and report to neovim repo if there is something to reproduce

That would be great

[Rónán Carrigan]

Thanks for the fix by the way!