Fork me on GitHub

I remember something that values in the log buffer should be pretty printed. They don’t seem to be for me. Is that something that has to be enabled manually? Relatedly, is there a way to grep conjure’s docs from within vim?


So in the docs you can just hit / and search for what you need, it's just a buffer. As for the pretty print it should be working already! It's all set up to :thinking_face:


They have to be fairly long for it to kick in


It uses Clojure.pprint


Yeah searching a buffer with / makes sense, I guess I was more asking for a way to search all the help texts since there are multiple. Like in this case I’d have loved to just grep the entire conjure help for “pretty”


I have some 960 characters long output that isn’t pretty printed. Should that kick in at that length?


Ah I see! Yeah, I suppose a grep would be good but that's be a vim thing if it existed. I could add more tags then you could tab complete things too


Hmmm it definitely should pp!


When you enable debug mode (`ConjureConfig clojure.nrepl/debug? true`), does the eval nREPL message have pprint specified I wonder?


Also this may be a CLJS thing... maybe CLJS + nREPL doesn't allow pprint :thinking_face:


Yep, looks like pprint isn't working with shadow-cljs connections, but it works with JVM. I'm providing the option still, it's just being ignored. Let me check plain piggieback too, it might just be shadow-cljs (and babashka etc)


So I gave it a test, only regular JVM Clojure supports the pretty print argument on eval. Shadow, babashka and a regular piggieback+node all ignore it.


Also, :helpgrep is a thing! I had no idea, so you can use :helpg eval-replace to jump you to the docs on eval-replace!


Or :helpg shadow for shadow-cljs stuff


Thanks for looking into it! do you know if this is an issue with Shadow or some CLJS nREPL tooling?


I think it's an issue with all tooling other than Clojure JVM nREPL


I've asked about it on one of the dev tooling channels


did anyone experienced this issue with the params of the doc when using K?


Ohhh you're getting CLI highlighting in your doc output. I presume you have something like rebel readline installed (or similar)?


If I can solve this you'll get highlighting there


I'd imagine you have a lib or some middleware that's colouring the output though. Or trying to.


right! i have ultra now when i removed it, it looks great!


Yep, that'll do it! I would love to support those terminal escape codes and add colour, it's just sort of a long term goal and something I think can be served by another plugin that others have written.


I'd rather not implement it all myself, I'd rather find another project that works well and recommend that for those that REALLY want those terminal colours displayed. Personally, I never see them in any of my output, I think some test runners insert them though.


i still think has promise, they just need to sort out the luajit issues


oh, never mind - they apparently don't support the ANSI terminal color escape codes yet


it would also be great if colorizer could sort out their consistency issues. the maintainer doesn't seem very responsive


I'm going to store the previous result of each eval so you can paste it wherever you want, a bit more flexible version of eval and replace. Poll: Should the mechanism of storage and retrieval be... 🍎 Based on built in registers, you configure which one (maybe c by default), so you can just use "cp to paste, or access them in Vim Script etc. 🍌 Stored in a variable inside Conjure's Lua, separate to registers, and pasted with a specific mapping such as ep or pe. (the latter allowing for maybe pd for debug info or something in the future. Basically just a "paste something" mapping. 🍊 A hybrid. Put into the black hole register by default and you use pe (or whatever) to paste, but you can set the storage register to " (default) or C etc then use regular register mappings if you want to.

🍎 12
🍌 4
🍊 4

Also you don't have to vote if you're not sure, let's discuss!


I kinda like the built in registers approach since you could set it to the default register, then get paste history, and just hit p or P to paste after an eval. This would wipe out whatever you just yanked, but so does editing. And this could be an option for those that liked it, you could always set it to the black hole _ if you didn't want it or c etc.


Maybe both? Like default to _, let people do what they want with it, but also have a special paste mapping which isn't as flexible but doesn't interfere with registers.


the idea you just mentioned about using the default register sold me on that idea


and in general, i like the idea of leveraging basic vim features


the vim purists would like that 😄


So if I go down that route, I basically simplify SO much of this


Because my paste system will always be worse and quirkier than vims built in one


I am worried my register system will get bloated and overused


And just saying "put previous results in this register" will work a lot better in practice


I may throw out the implementation on develop in favour of a config that lets you put your results in a normal register. Not only is it much easier to implement, it's easier to get right.


Can't decide on the mapping for this :thinking_face:


I think <prefix>pe by default since it leaves more room for paste mappings.


Currently basically implementing my own paste and register system 😬


Develop allows you to paste previous results before or after the cursor as well as over a visual selection I hope it works well!


It goes hand in hand with "replace this form with the eval result".


Let me know what you think 😄


If you like this kind of Conjure specific paste register I may add things like "the code you last evaluated". Plus anything else useful I can think of.


would it be useful to store *1, *2 and *3 in registers?


ditto for *e


then i imagine you could do (assuming \ is your prefix) \p1 to print *1, \p2 to print *2, \pe to print the last error

👍 4

no reason that \pr couldn't also print the last result, i.e. *1


i'm not sure how much i would actually use \p2 or \p3 though


i barely ever use *2 or *3 in the repl


That's basically where I'm going with it, yeah. That'd be a Clojure specific extension to the general idea of "Conjure can paste things"


<prefix>pr is useable in any support Conjure language right now. The *1 *2 *3 would be Clojure... or I implement 1 2 3 in a generic sense as well


I wanted to float the idea of this paste system first before adding more registers


Although last error would be very tricky since the client then needs to signal when a result is an error. Some clients won't know.


You can already do <prefix>ve then <prefix>pr to print the last error


"view exception", "paste result"


ah, that makes sense


I'll let this feature sit for a bit, see what people think then decide if I should invest more into it and how 🙂


i suppose providing \p1, \p2, \p3 and/or \pe could be a clojure specific extension?

👍 4

I may well throw this out in favour of just putting it in a normal vim register for you to use (and configure). So don't get too attached to the p and P prefixes 😄


that sounds good to me too. "cp or something is just as easy to type


i imagine you could just put values like *1, *2, *3, *e into lua variables or whatever and then users could write their own mappings if desired


oh wow, I didn't know you could do <prefix>ve to see the full exception, that's awesome


very cool to have a summary, but then be able to drill down if needed


Yep! It's just raw data right now, so it's pretty ugly, but it does contain all the info you need.


I'm holding off prettifying it until I have an idea of how to make interactive things you can collapse and explore. Like being able to hide massive results and explore them in an async interactive way, maybe using a 3rd party tree explore plugin. (I think vim-iced does this and it looks awesome)


I'd love to say "this is too big, here's the top level, hit enter on things to request the rest" or something like that. A long way out though, lots more QoL low hanging fruit first!


Yes! on all of this. Too often, I push way too much data into the log buffer and have difficulty navigating it


Hi all! Can I config on which side the log will appear when I do <local-leader>lv ? I couldn’t find the specific config through the help doc