This repository has been archived by the owner on Aug 12, 2023. It is now read-only.
Replies: 1 comment
-
Yeah, the Plenary API isn’t the easiest to work with. I’ve been meaning to look into some of the solutions in this issue, since our usage here is very simple. Theoretically I think nested async functions should work. If your goal is to wait for a list of futures to settle, you should be able to use the relevant code here as an example. If you can link to your WIP code, I can take a closer look, too. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey 👋🏾
I locally work on a branch of my fork which added support for code lenses. I want to try this a bit with my own first code lens sources.
One of them is a simple replicate of the VSCode code lens that shows the number of references for a symbol and on "action" shows them. Focusing only on the first part - showing the information as code lens - I struggle to make it properly asynchronous.
The code lens support in null-ls is pretty straight forward. So nothing special to it. So it just calls the generator functions of the registered sources that support this method and calls the handler.
The source itself now looks like this as a generic description:
textDocument/documentSymbol
textDocument/references
The critical parts are 1. and most importantly 4. The whole generators sets the
async
property and uses thedone
callback. For 1. I currently still have thevim.lsp.buf_request_sync
call. For step 4. I useclient.request
with a callback and thenvim.wait
until all parallel requests are finished.This is okayish, but ofc not really good. I would like to learn how to use
plenary
to write proper async code to create a "future" for eachtextDocument/references
call and await them all. But I'm also confused as from reading thenull-ls
generators code, the source generator function is already wrapped into a future byplenary
. So I don't really know how this works from here. Like we are already asynchronous, but it is not.I currently use an autocommand to update the code lenses (
vim.lsp.codelens.refresh()
) onLspAttach
andInsertLeave
and I notice the blocking when leaving insert mode. It was quite worse before I "parallelized" the LSP calls for references. So it is blocking atm.Sorry, I know this might sound very stupid, but I really don't know how to write proper asynchronous code in Lua for NeoVim.
Thanks for any help!
Beta Was this translation helpful? Give feedback.
All reactions