textlock umbrella issue

[jmbuhr]

Issue

Currently we call sync_raft on a request to update the otter buffer and forward requests to up-to-date attached servers.

otter.nvim/lua/otter/lsp/init.lua

Line 131 in ca9ce67

local success = keeper.sync_raft(main_nr, lang)

but this uses the set_lines api, which does not work when textlock is set:

otter.nvim/lua/otter/keeper.lua

Line 396 in ca9ce67

api.nvim_buf_set_lines(otter_nr, 0, -1, false, ls)

This happens for example when a plugin uses the CompleteChanged autocommand and an lsp request is sent from within this context (which then reaches otter.nvim as a request).

References

https://neovim.io/doc/user/api.html#nvim_buf_set_lines()
https://neovim.io/doc/user/eval.html#textlock

Related

#145

Affected issues

#182, #178

[TheLeoP]

I had an idea for a naive solution and after some really naive tests it seems to be working. So, I'm putting it in here to see if I may be missing something obvious about why my solution won't work.

If the whole request function is wrapped in vim.schedule_wrap, this error won't happen because will never be in a textlock while changing the otter buffers.

i.e.

        request = vim.schedule_wrap(function(method, params, handler, _)
        -- the body of the request function is still here
        end),

[jmbuhr]

Great idea! I wonder if it would be enough to only wrap the relevant part of sync_raft, since it can then take advantage of the fact that is doesn't have to run when the buffer hasn't changed.

Do you want to open a PR (with your solution)? Preferably also with an example that doesn't work with the current implementation, but works with your solution.

[TheLeoP]

Great idea! I wonder if it would be enough to only wrap the relevant part of sync_raft, since it can then take advantage of the fact that is doesn't have to run when the buffer hasn't changed.

My first thougt is that it may be messy because:

• If the schedule is done inside of sync_raft, the bufferts wouldn't be sync when the function exits. They would be synced in the next event loop iteration
• If the schedule is done in the middle of request, you would need to plut all the code following sync_raft inside of it (because of the reason above) to keep it working

I don't know the codebase and I'm wokirng under the assumption that after a sync_raft everything should be synced or else the following code won't work. This may not be true, but I can't really tell

[jmbuhr]

I think you are right.

[jmbuhr]

Re-opened due to regression.