Fork me on GitHub

I would imagine this setting takes the value of where splitright etc., are set, i.e., ":help splitright" or ":help splitbelow"


@joao.micena yep, @dharrigan is correct! Conjure doesn't do anything special here, it literally calls :split or :vsplit so it relies on your Neovim configuration for new splits. If you really need your normal splits to go one way but Conjure's log to go another way I suppose I could consider some sort of option for it, I just like relying on the built in options where possible.


Wondering what the default register for Conjure's results should be :thinking_face: I want a middleground, so configuring it to " would be "I want every eval to go to the main clipboard". c or C would be a good non default one that's easy to access. _ would disable it entirely if you don't want your registers messed with. Not sure if I should use c or C as the default, worried c might be used by someone's macros or whatever.


Maybe not.


I'll go for c for now.


Got it working! And ConjureConfig eval.result-register "\"" works! So I can bind every one of Conjure's results to my default clipboard. Just eval anything then hit p or P as usual. Or even create Vim Script mappings that rely on the register contents!


And it's on develop if anyone wants to give it a go! I'm going to try it with it set to my default register but the default for everyone else is c for Conjure. Was considering r for result, but I'll leave it as Conjure to indicate "this is the only register Conjure will use"


If I use r it implies there could be more in the future but I don't want that.


Also if your Neovim config is in Fennel (via Aniseed) you can just require Conjure and access the functions directly 😄

(module dotfiles.module.plugin.conjure
  {require {config conjure.config}})

  {:path [:eval :result-register]
   :val "\""})

😎 8

Hmm the * register seems to always take precedence over " which sucks. That's set when I select any text in X 🙃


I set eval.result-register to * instead and it works great


if you can't beat the * register, join the * register ¯\(ツ)

😂 4
Olical11:05:05 playing with the register and eval + replace form


Think I'll just wait to see what people think of these eval+replace and clipboard features then get them release 😄 next release after that will probably be some improvements to the HUD display logic and :ConjureSchool


I got too excited about improving the HUD logic and did it anyway, it's on develop. So now the HUD will only appear if the last line of the log is not visible in your current tab page.


So. That means you can open the log and edit / eval things above the last line. The results will appear at the bottom. As long as the bottom of the log is still on screen, it won't pop up. As soon as the results get long enough to go off of your screen, it will pop up. If you scroll the buffer to bring the last line back on screen it'll stop appearing.

🙌 8

Here's what I mean: let me know if you break it 😄


I like your enthusiasm


I have to play with the eval clipboard stuff, but not got round to reviewing yet


What do you use to record asciicinema stuff?


The asciinema client, it's suuuuper neat


Ah, so this eval + replace, allows you to take the contents of the eval buffer, put it in a reg, then paste it directly into your file?


Not quite, they're two different systems that cover different use cases. Eval form and replace is for when you want to do some math or something then replace the code with the result


The clipboard (register) is just for general "I want to paste the result here"


so the eval and replace is a specialisation of the same idea


but they're a little different in why you would use them and when


Would it be possible to automatically attach a .then whenever nREPL’s return value is a promise? Eventually trying to do something like (.then p #(do (def my-known-var-for-the-last-promise-ret %) %) So that I could access the last promise value via something like *e I guess that’s the kind of thing that you’d use nrepl middleware for? :thinking_face:


Hmm it sounds pretty damn tricky but neat. Also presumptive? Like if you wanted it then good, if you wanted your promises to behave normally it'd be really surprising.


Middleware would be best, especially if it runs in CLJS land and it can inspect the type of the object


by the time it gets to Conjure I'd be running regexps on the result string for something that makes it looks like a promise which is a big nono for me.


You could set up a custom mapping that uses :ConjureEval ...


So you could build a chunk of code that used *1 (previous eval result)


Or even the new result register on develop (all results are stored in the c register by default at the moent)


Then any time you see a promise, you hit your mapping and the result gets printed.


I suppose tap> support would make that even easier. I need to get that hooked up!