Fork me on GitHub

Might be post release but I'm thinking of writing these guides up on the wiki or something. Others can contribute if they want too!

👍 16

Any thoughts? More that should be added?


These aren't going in :h conjure because they're not to do with Conjure as a plugin, they're to do with the thing it connects to. But @rafaeldelboni is right, it'd be a good idea to have some simple guides for these things.


(and thank you so very much for the sponsorship, @anthony550! Let me know if you need anything! :D)

👍 4

that looks very good to begin with!


I think this is probably my most visited page over the last few months 😄

😂 4

Pushed a bunch of changes today, just fixed and improved stuff as I saw it, please let me know if you spot any issues! The most notable thing is handling of split "out" and "err" messages (@nate) So if you println > 1024 bytes nREPL will send it in two messages, Conjure should now batch those up and print them on the same line where required.


It basically allows you to call multiple prints then see the results when there's a newline


So (do (print "foo") (print "bar") (print "baz")) ends up printing ; (out) foobarbaz in the log.


It'll look for a newline to print early but will always print whatever it's bulit up when it sees a final result.


I'm making tradeoffs here, yes I'm not printing to the log right away if you print something without a trailing newline, but I'm keeping the output consistent with what you should see in a terminal REPL. I think it's for the best.


And @nate, I will try to tackle the trimming issue soon, this is just a first step to improving stdout handling 🙂


This batching of "out" data took a 37 line stateful wrapper function around the existing result printing function 😬 was pretty tricky, but I think it's worth it for the log output looking as you expect when compared to a regular terminal.

💯 4

Oh wow!!! Thank you for fixing this. I'll try it out today and let you know how it goes.


In zsh, if there's not a newline on the end, a % character is output. You could perhaps do something like that too. You could also append as long the current line is an out line.


Hmm I think it might still break output. It'd be simpler, for sure. Some stuff would get formatted weirdly though. I have to jump through some hoops to make it look like a normal repl output


Yeah. I like my second suggestion more :)


Maybe it's just me, but I like seeing the live progress of these things. I rely on the timing of prints being accurate.


I agree with you here, and I didn't enjoy introducing stateful wrappers (even if it's hidden in a higher order function). I'll try checking if the last line is an our or err line and appending to that and see how it goes :thinking_face:


If I get the same results but it happens right away and I can delete a highly complex function then I'm happy.


Yep, that will work as long as you're printlning


I'm on the fence about this change right now. It's so complex to implement it might not be worth it


@olical I just checked the latest change with my code that prints out a really long string and it worked perfectly

🎉 4

Improved how the trimming works @nate so you should see blank lines and whitespace in your stdout where you expect them. Going to experiment with simplifying how partial prints are rendered too.


@olical awesome, just checked it out and it works perfectly. thanks for the fix


Sweet! I'm going to see if I can simplify the print / println (newline or no newline) handling though, because holding onto stdout (even for a tiny bit of time) could cause some inconsistencies when compared to your plain terminal that I want to avoid. Would probably never be a big deal but might confuse people at annoying times.


See if I can get it to behave like Dominic mentioned, immediate but append on the same line if possible.


(defn last-line []
  (a.first (nvim.buf_get_lines (upsert-buf) -2 -1 false)))
Fennel + Neovim ❤️


Get the last line of the current log buffer for the given language (taking into account callstack local language overrides)


Also cool how the eval result of this is the line that describes what I evaled... META!

; --------------------------------------------------------------------------------
; eval (current-form): (a.first (nvim.buf_get_lines (upsert-buf) -2 -1 fal...
"; eval (current-form): (a.first (nvim.buf_get_lines (upsert-buf) -2 -1 fal..."


Because it prints the comment, then runs the code, which returned the comment.


I've got dangerously used to altering software with itself.

wizard 4