Casually making a 14k line commit as I migrate the sourcery repo into the main repo develop branch 😬

It's nice to be committing to the main repo again! 😄

Can we start testing away?

It's usable, although I might break it if I'm not careful during development and there's no docs 😬

If you want to give it a little trial run then be my guest! It should work. The only way to connect right now is have a .nrepl-port file, I haven't added commands for connections just yet.

Might want to leave it a little longer really so I can get docs written up and a few more features filled in. No autocomplete etc yet.

Alright - I'll try and be patient 😉

I appreciate the anticipation though! I'm genuinely excited to get this polished off and into everyone's hands so I can continue to improve it from feedback.

I just really hope the route I've taken with the UX is okay, I'm worried some people are so used to the virtual text for results etc that this will be too different and they'll hate it.

I'll keep the old version on a branch or tag so people can still use it if they really want, but I think my new design is objectively better.

Just different, which might cause people to be like "ew no, why"

As far as UX goes - it's your lib so your say-so. Personally, I"m pretty adaptable to most UX things and I prefer the new direction over the old one, so :thumbsup:

Well that's good to hear. Virtual text is okay, but I realise I should only use it for small hints relevant to the line, not full eval results, it's too small and confined. A floating window gives us full syntax highlighting, multiple lines and absolute positioning anywhere within the editor.

I may end up using it to show function signatures under your cursor at some point, I think that's a better use.

:thinking_face: tempted to just push for docs right now so develop is usable and I can get some feedback. It'll still be lacking things like completion for a little bit but it'll be usable for eval/doc/go-to-def over nREPL.

I think I will. I want to get it in your hands ASAP, especially for those that need an nREPL capable system for CLJS stuff.

https://clojurians.slack.com/archives/CK143P6D7/p1586516287267400 I would really like this. I think I'll be one of the people who miss the virtual text. I understand why the floating windows are superior but often what I want to do is short evaluations where I'm interested in just seeing a quick result and virtual text is great for doing that in a way that doesn't interrupt your flow. But what it's really great at is function signatures and so if that got implemented (in due time) it would be terrific.

Oh, and to be clear, what you've shown in the screencasts looks amazing. It's just not my particular workflow (at the moment) so I'm a little cautious about how I'll adapt to it. But even with that, I very much support the overall direction and am really excited about the entire project.

Yep, I appreciate that change might not suit everyone. I strongly feel that a small buffer is better for eval results than virtual text, but time will tell. I hope you'll grow to prefer this way since it's always in a consistent place like a notification. You can totally ignore it in your peripheral vision if you're not interested in the result too. Using virtual text for passive hints rather than active feedback from an action just feels right to me at the moment. We'll see though! Maybe I'll add an option for virtual text eval results at some point too!

The main benefit is you get more context (since you're viewing a bit of the log buffer) and you get syntax highlighting of the result.

You'll also see much more of big results, they won't just vanish off the side of the window

https://clojurians.slack.com/archives/CK143P6D7/p1586519206281500

This is the thing that I find the most appealing. It's definitely the biggest problem with the virtual text approach in my experience.

I mean you could always open the log if it was too long, and you can do the same in the new one. I just really like that I see a big result in the top right, hit the log split button and then it's the exact same buffer in a window I can interact with. The same shape, formatting and colour. There's just less of a jarring "oh this is a particular view of this thing". There's one way to view your interactions with your REPL, the log buffer, and a few ways it's shown to you. I think the visual consistency helps a bit.

The other thing I'm really excited about is the possibility of using this with other lisps. I know you've mentioned it a couple of times and just so you know: there is at least one other person really excited about that potential :D

Yay! There's literally dozens of us! The quality of the support will depend on how well I can translate the concept of namespaces to them, but at the very least you can have eval and results. The Aniseed + Fennel + Conjure trifecta will be great for Neovim plugin development too, that's what I'm using to write Conjure itself (yay, dogfood!)

I'm also really enthused about the nREPL decision. I say that as someone who wrote to you by e-mail to talk about how excited I was that you originally went with pREPL. I wish pREPL support were in a better place but given it's not—and given that almost zero has happened with it since it came out—being part of a larger community seems like a complete no brainer. I was reading about Calva in the latest Clojurists Together newsletter today and thinking about soon being a part of (what seems like) a growing ecosystem of editors using nREPL is something else to look forward to.

So much cool stuff! :D

Yep! I think prepl is neat and has it's place, but for people that just want to connect to CLJ or CLJS REPLs and have everything work right away, it's an uphill battle.

I'll be able to lean on CIDER etc if it's in your REPL which will be so good.

Sharing effort with so many other tool devs while keeping my own UX ideas.

CLJS completion 👀

I'll still write a prepl implementation in an optional repo at some point too, just in case it suits someone's use case perfectly. It just won't be as feature rich but you'll get the same UX and interactions.

You can just swap out which Clojure support you want in the new Conjure while keeping the outer shell.

it's always great when you can answer the question "should we do X or Y?" by making some sort of interface that allows you to plug either X or Y in 🙂

https://media.giphy.com/media/3o85xIO33l7RlmLR4I/giphy.gif

precisely!

Conjure: Why Not Both Edition

"which language does it support?" "yes"

https://github.com/Olical/conjure/tree/develop starting the readme introduction for the new version

All documentation will be provided through vim help files so you have access to it at all times, even when offline

(it doesn't exist yet)

I'm aiming for the readme to be short and sweet, showing you what it can do, how to install it and how to learn more.

good strategy

Just waiting for that prepl support before I can try it out. 😄

oh wow, this has been happening to me too!