Use fireplace#native()
Closed this issue · 16 comments
I'm changing the semantics of fireplace#platform() to lazily connect. If you're not ready to move to message() (why not?), you'll need to call fireplace#native() to get an object with a transport attribute.
I am not quite ready to switch yet because I'm waiting for an easy way to do streaming results where the UI is blocked but new echo output appears.
If you're counting on neovim/neovim#10362 to solve it, you may want to make your request more specific, as I just tried the waituntil branch being workshopped there and it fails to meet your echo requirement.
Vim handles this just fine with a while loop wrapping sleep 1m.
A polling loop invoking jobwait([transport.job], 1) seems to work. I've added fireplace#wait(fireplace#message({...}, callback)) to encapsulate this. No more excuses!
Using jobwait() means ctrl-c kills the connection. A regular sleep 1m is working fine for me with :echo now (I swear it wasn't before) so I'm switching to that.
haha, fine, fine. You got me! I'll try and find some time today to do it!
fireplace#wait() behaves slightly differently to how things were before. Consecutive calls to :echo were additive for example.
It's additive on master for me. I did see the non-additive behavior when I first started implementing it. Can you try with a stripped down config?
Actually, I'm being daft. call fireplace#wait({'op': 'refresh'}, function('MyDebug')) isn't working at all. Where
function! MyDebug(...)
call add(g:Debug, a:000)
echom string(a:000)
endf
So basically just a boring debug fn.
You're need to call fireplace#message() and pass the result to fireplace#wait().
echo fireplace#wait(fireplace#message({'op': 'eval', 'code': '(do (Thread/sleep 10) (println "out") 10)'}), function('MyDebug')) Still not much luck with this. I notice that fireplace#wait double wraps the the {}. But I didn't have success with a single manual wrap either.
Oh, I'm daft. I see the problem. Ugh.
That works fantastically. The only problem I need to figure out is how to force a clj connection from within a cljs file. For the refresh operation that should always run in the JVM, even when run from a cljs file. You'd usually use it to start a web server.
I should probably clarify that the evaluations I send to find the stop/start need to be run in the JVM. So it's more basic than that.
fireplace#clj().Message() will work. fireplace#message() is equivalent to fireplace#platform().Message(), which uses fireplace#clj() or fireplace#cljs() based on the current file.
Awesome. That works perfectly. I'll do some more testing tomorrow, but I think this is ready. Do I need to worry about the fact I'm missing this section: https://github.com/tpope/vim-fireplace/blob/493eff65b95ce348c5f55545a7607e05743610fb/autoload/fireplace.vim#L993-L996 I don't understand it's impacts exactly.
It looks like it sends the ns as true, and I'm guessing the python code is going to do something with that, but I'm not sure.
v:true forces it to use the namespace of the current buffer, the same as Fireplace's usual eval behavior. If you're running clj code from a cljs file you probably don't want the behavior, but you can pass "ns": v:true yourself if you do.
This is now done, I've backported all of the replant async functions to use fireplace.