Clojurians Log v2
conjure
I remapped ConjureConnect to ,cu...old skool 🙂
Haha, the old ConjureUp command 😄 I did kinda like that "describe what you want, I'll sync it" thing but it did mean learning a whole new concept. It didn't sit right with me since you had to learn this whole conjure.edn thing then everyone ended up using the exact same "just load my .nrepl-port file" config anyway 😅
sometimes I quit out of the repl, then come in, and I want vim to reattach to the running session
You mean automatically as the repl comes up? Because I guess you could have a little set interval checking for that sort of thing :thinking_face:
If you're suggesting what I think you're suggesting, that's been on my wish list for a long time too
like ideally, i shouldn't have to press ,cf to reconnect every time i restart my nrepl server
:thinking_face:
Simpler: On any operation that requires a connection (I already have this path running through a single check function), if there is no conn, attempt to connect to a port-file in the background passively before proceeding.
Consider this TODOed
Also could tie in well with https://github.com/clojure-vim/vim-jack-in/issues/5 which I'm thinking about doing.
So you could open foo.clj, run :Bb (or whatever) then just eval.
And likewise, open Clojure file, :Clj, eval
i like that idea!
i think that would take ,cf out of the equation entirely
although it might still be nice to have it around in case it's needed
I work in a machine over SSH that's on another continent day to day to pair with my team, this means I hit weird edge cases with Conjure I'd never normally find locally. There's one in particular where the HUD seems to get out of sync then all eval results won't show unless I have the log open (to remove the need for the HUD). Not sure if anyone else has seen this weird state / race condition bug, but just a heads up that I have it on my radar to squash. Very soon. I'll make the HUD state auto heal, so if you somehow kill the window without Conjure knowing (thus putting it's state out of sync) it'll just deal with it instead of going "aaaaa can't close window X, it's gone already".
Yeah, I'd still keep it just in case, but it'd be useful. Probably on by default but flagged behind yet another option just in case someone doesn't like it. Some people prefer every action to be intentful+specific, and I want to support that behaviour. I just think this as the default is safe and useful.
Yeah, something that is automatic, but not too heavy on constant polling would be super dooopar awesome
try to restablish a connection on the first attempt to do anything with the nrepl
(if connection is not already established)
Zero polling 😄 I hadn't thought about it when I suggested that.
Yep, exactly
With fireplace I use https://github.com/guns/vim-clojure-highlight; does anyone use something similar with Conjure?
Ohhhh this could totally be forked and adapted to Conjure!
3👍Or even a whole new plugin so it could have CLJS support (which isn't in the original)
Any suggestions on troubleshooting omni-complete slowness? It takes a couple of seconds to pop up. (I'm not working with deoplete, yet)
Hmm that's really odd... and all other evals seem okay? Like go to def and that sort of thing?
It's just omnicomplete that's slow? And I guess not just the first invocation but more after that too?
(conjure really doesn't do much here other than pass things through, so we're relying on CIDER really, and that's pretty battle tested)
Yes, not just after the first invocation. I thought I had noticed some eval slowness, but nothing like the omni complete. I do have some projects with very large namespaces. You're right though, I'll investigate CIDER issues and my setup there. 🙏
I compared omni-compete by eye -- no real measurement, so take this with a grain of salt -- on the same project in our largest namespace once using fireplace and once using conjure. It took 2-3 seconds to run omni-complete with vim-fireplace and 4-5 with conjure. I don't know if this additional context matters, but I was autocompleting after typing the namespace fragment + "/", which I mention only to note that I wasn't trying it after 2 characters.
All of this to say, we're certainly at fault for having huge, unwieldy namespaces, and wrap-complete is definitely getting forced to do a lot of heavy lifting. Though fireplace may be processing those results more readily.
I don't expect this to be any kind of priority, of course, just thought I'd share my informal observation
:thinking_face: thank you for the information! I guess if there's LOTS of results I could be doing something inefficient while processing the results, I could definitely try to optimise that. Are there lots of results as far as you can tell? Like, thousands? LuaJIT is pretty damn fast (understatement) and all I'll be doing is mapping some strings into some tables, something that's pretty simple.
I suppose there could be some things in here I could make faster (looking at the source). But not by much, I'm wondering if I'm doing more work up front to extract the context, I guess Fireplace does the same? (like it sends the context code so you get (let [...] ...) completions? That's unlikely to be the culprit, but let g:conjure#debug = v:true might highlight it. It'll show how quickly the completion request is sent after you request completions at least. And how many results you're getting!
I've pushed some slight optimisations to develop for this, you may notice a difference! I've never had enough completions to cause a slow down really, so I should probably try to reproduce this and work at making that faster.
Oh, wow. Thanks a bunch! I'll take a look at this as soon as I can!
I'm semi-concerned it'll make 0 difference, but I replaced a bunch of higher level function calls with much simpler direct calls out to Lua builtins.
So maybe it was my fn overhead in a tight loop that was causing it to be O(n^2) slow or something like that