Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-05-06

Channels

#conjure
<
2020-05-06
>
martinklepsch10:05:25

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?

Olical10:05:19

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:

Olical10:05:28

They have to be fairly long for it to kick in

Olical10:05:36

It uses Clojure.pprint

martinklepsch10:05:04

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”

martinklepsch10:05:29

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

Olical10:05:43

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

Olical10:05:50

Hmmm it definitely should pp!

Olical11:05:40

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

Olical11:05:20

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

Olical11:05:39

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)

Olical12:05:50

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.

Olical12:05:55

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!

Olical12:05:50

Or :helpg shadow for shadow-cljs stuff

martinklepsch13:05:42

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

Olical13:05:28

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

Olical13:05:38

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

danabor11:05:36

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

Olical11:05:12

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

Olical12:05:55

If I can solve this you'll get highlighting there https://github.com/Olical/conjure/issues/53

Olical12:05:01

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

danabor13:05:43

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

Olical13:05:27

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.

Olical13:05:09

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.

dave14:05:32

i still think https://github.com/norcalli/nvim-terminal.lua has promise, they just need to sort out the luajit issues

dave14:05:06

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

dave14:05:36

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

Olical12:05:22

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
Olical12:05:06

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

Olical12:05:39

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.

Olical12:05:02

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.

dave14:05:34

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

dave14:05:52

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

dave14:05:02

the vim purists would like that 😄

Olical14:05:30

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

Olical14:05:41

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

Olical14:05:54

I am worried my register system will get bloated and overused

Olical14:05:07

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

Olical14:05:18

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.

Olical13:05:49

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

Olical13:05:02

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

Olical13:05:22

Currently basically implementing my own paste and register system 😬

Olical14:05:20

Develop allows you to paste previous results before or after the cursor as well as over a visual selection https://asciinema.org/a/327290 I hope it works well!

Olical14:05:28

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

Olical14:05:37

Let me know what you think 😄

Olical14:05:44

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.

dave14:05:54

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

dave14:05:58

ditto for *e

dave14:05:28

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
dave14:05:40

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

dave14:05:15

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

dave14:05:23

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

Olical14:05:24

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"

Olical14:05:55

<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

Olical14:05:06

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

Olical14:05:48

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.

Olical14:05:51

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

Olical14:05:06

"view exception", "paste result"

dave14:05:19

ah, that makes sense

Olical14:05:39

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

dave14:05:46

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

👍 4
Olical14:05:07

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 😄

dave15:05:13

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

dave15:05:45

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

nate16:05:18

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

nate16:05:29

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

Olical16:05:47

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

Olical16:05:38

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)

Olical16:05:13

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!

nate16:05:10

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

jpmicena22:05:27

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