It's kinda frustrating that s:get_complete_context cannot be trivially rewritten to use a specified location rather than the cursor. e.g. for command line completion. It's only minor I guess, but it would be nice.

(more of a vim complaint hat a fireplace one)

Ctrl-X Ctrl-O seems to be giving me a E745: Using a List as a Number and not filtering the results.

Your example never gives me any hits, but fireplace#omnicomplete(function('callback'), 'yad') does (filtering for "yad" typed in)

anyway, this is working an absolute treat with asyncomplete. I'll give it a test in the slow env.

I've hooked this up to a local change to async_clj_omni, and with asyncomplete this is really snappy, great! (and not much code either!). I've introduced a (Thread/sleep 3000) into cider-nrepl to observe the effects of delays on locking up:

diff --git a/project.clj b/project.clj
index 079a19d..2487431 100644
--- a/project.clj
+++ b/project.clj
@@ -1,4 +1,4 @@
-(defproject cider/cider-nrepl "0.21.1"
+(defproject cider/cider-nrepl "0.21.1-SLOWMO"
   :description "nREPL middlewares for CIDER"
   :url ""
   :license {:name "Eclipse Public License"
diff --git a/src/cider/nrepl/middleware/complete.clj b/src/cider/nrepl/middleware/complete.clj
index 2a9e733..5a5d8e7 100644
--- a/src/cider/nrepl/middleware/complete.clj
+++ b/src/cider/nrepl/middleware/complete.clj
@@ -25,6 +25,7 @@
     (jvm-complete/documentation (str symbol) (u/as-sym ns))))
 
 (defn complete-reply [msg]
+  (Thread/sleep 3000)
   {:completions (complete msg)})
 
 (defn doc-reply

I think bfredl mentioned he'd introduced an asyncish implementation in his plugins, probably for julia

oh yeah, I mis-remembered what fireplace#omnicomplete(1, '') did. you'll need to use that integer to extract the keyword from the current line

looks like getline('.')[fireplace#omnicomplete(1, '') : col('.')] will do it

regarding the asyncish implementation by bredl: https://github.com/bfredl/nvim-ipy/blob/14d2399ead1d7cf9e8aa6cdbe6c7bf241be76026/rplugin/python3/nvim_ipy/__init__.py#L346-L357 he has a custom binding which he binds to C-f in his special repl buffer.

this just calls complete() later. So it's not magical 🙂

Putting a 3s delay into complete has some really interesting effects on clients.

I have working local copies of async_clj_omni with ncm2 now also. ncm2 is a fairly major async completion plugin, so that should cover most things for most people.

using that asyncomplete branch?

i can ship that branch if you think it's ready

I'm still getting issues using Ctrl-X Ctrl-O with that branch

https://clojurians.slack.com/archives/C0DF8R51A/p1563610249000800?thread_ts=1563488411.003500&cid=C0DF8R51A

https://clojurians.slack.com/archives/C0DF8R51A/p1563632473002600?thread_ts=1563488411.003500&cid=C0DF8R51A

https://clojurians.slack.com/archives/C0DF8R51A/p1563633196002800?thread_ts=1563488411.003500&cid=C0DF8R51A

if you mean it was happening on that branch just with the built-in completion, possibly, but the latest rebase i pushed up today is working fine for me

I'll give it another go. But yeah, I meant with built-in omnicompletion. Worked great for me 😛

As an aside, you can definitely remove the async code intended for use from Ctrl-X Ctrl-O.

Hmm, in neovim I'm still not having success with Ctrl-X Ctrl-O

ah, nvm. Looks like it's something on neovim master, so unrelated. Great 🙂

it behaves kinda strange on neovim 0.3.8 too though. Very odd :thinking_face:

seems fine on my old 0.3.8 install

does it also behave strange on master? afaik this branch only adds an async api, it shouldn't affect ctrl-x ctrl-o

Maybe it's something environmental. If you have it fine on 0.3.8 then it should be okay 🙂

just shipped it, looking forward to seeing what you rig up

will merge my equivalent branch to master 🙂

i'm open to adding this to fireplace proper once you're confident it's stable

https://github.com/clojure-vim/async-clj-omni/blob/master/autoload/async_clj_omni/sources.vim#L2-L8 stuff like this should be replaced with a call to fireplace#omnicomplete(1, '') to get the column fireplace thinks it should start in

aren't those essentially equivalent?

fireplace uses \k\+ which is presumably the same with the default value of iskeyword

but it's not a guarantee. technically it should include ' in all but the first position. if i fix that your code will break

i guess it depends on the interface you have to implement though. the omni function is looking at the current line while it looks like asyncomplete passes in a typed field?

Yeah, assuming that the regexs match the same thing then they are equivalent. Yeah, asyncomplete etc. provides a 'typed' field, and pretty much all the completion plugins do. coc.nvim seems to use \k\+ as an 'input' field. I need to dig deeper to figure out if those are conveniences or if they're key to how the plugins work. At the moment the only risk is that you will occasionally get/not get certain locals so I'm not too worried about the fireplace side. I am less worried about it because I understand it. coc.nvim is 40k lines of typescript, much harder to understand.

@dominicm is this the same as your issue? https://github.com/tpope/vim-fireplace/issues/353

holy cow, latest neovim passes '1' rather than 1 as a:findstart

ah, that makes sense 😂

but yeah, that was my issue.

did you open an issue on neovim?

no, too much else on my plate

https://github.com/neovim/neovim/issues/10604 done

https://github.com/neovim/neovim/issues/10604#issuecomment-515420364 this was a vim bug.