Fork me on GitHub

I’m not sure what REBLs API is, but I recall that in his demo Stu was using it from inferior-lisp (yeah, yeah - I can’t imagine someone is still using this). 🙂


Likely basic integration would be trivial, but the real point is whether that’s the right approach. Frankly, I think it’d be much better if we just extended the inspector to support the new nav and datafy protocols.


A native Emacs UI will be much better than firing some Swing app IMO.

👋 20

That being said - I’ve got no plans to work on this, so if it ever happens it will have to be contributed by someone else.


FWIW, I want to stick as much as possible with Emacs when it comes to Clojure development. As much as I appreciate the effort put behind REBL, I really don't want another tool for Clojure interaction.


Well, there has also been the Swing inspector as well, but I’ve noticed that almost no one uses it. 🙂 I appreciate the idea of creating something tool-agnostic, but obviously it will never match what you can do with native integration.


Tool agnostic can potentially be better than what Emacs can do, because there are very expressive systems out there


Nrepl can and should support this workflow.


@dominicm I meant UI-wise. Emacs users simply don’t like to spin some external apps if they can have a native UI. As for nREPL - I totally agree. Probably using nav will be the solution to our “how to handle big results” conversations. Haven’t had time to think about how exactly to integrate datafy and nav with nREPL, though.


Don't they? Even if it's convenient to launch, and offers a superior UI? Interesting.


it'll be cool to use cider-inspect's user interface with datafy and nav


I’d gladly drop CIDER inspector for a GUI app, but I’m a recent convert to Emacs land 🙂


@dominicm I’m not sure REBL offers a significantly superior UI to what could be achieved in GUI Emacs. Maybe the web browsing stuff wouldn’t be achievable but the rest would.


To me the only big advantage of an external application is that it might have a dedicated maintainer. (Not sure if Cognitect are committed to REBL or it’s a proof of concept?)


@dominicm actually I take that back. I’m not much into ClojureScript but I guess exploring React components visually could be super useful

Chris Bidler18:12:48

FWIW my reluctance to “shell out” to another tool when using Emacs for Clojure work stems from the fact that I don’t have, as Stu briefly alluded to in the REBL talk, “you know, three big monitors, like we all have”

Chris Bidler18:12:51

so when I’m in a fullscreen Emacs session with my buffer and a REPL and maybe an ansi-term tailing logs or watching some kind of output, looking at “another tool” means swiping over to another desktop and back. Maybe REBL is the reason I finally buy some big external monitors and figure out how to drive them from my laptop? 😅


save your money and alt tab 🙂


I would appreciate having both tbh


I work in many contexts - laptop in a coffee shop, laptop + monitor at home, triple monitors at work


having a nice GUI with expressive visualizations would be quite useful. but the current REBL capabilities could be implemented in pure Emacs and would be quite useful as well


of course the dream would be: implement the core of a REBL-like program in some external program and have it output data to an adapter to be rendered in whatever context, allowing it to be downgraded. but that’s probably way too much work.


I highly doubt that the core of REBL is complex, so this is likely pretty doable.


I like the ideas behind REBL but I think Emacs should embed them, and while contributions flow, we can use that instead at the cost of some (minimal) context switch. At the end of the day Emacs is our Os right?


The experience does not seem hard to replicate either within emacs or in webkit - probably easier said than done 😃


I actually played with nav at the conj and there is surely the whole of the implementation for core protocols missing at the moment - if I understood things correctly


@bozhidar so in a cljs conversion frenzy I am bashing on orchard and adding reader conditional whenever it makes sense. Haven't been refactoring any code but the goal as I was telling you at the conj is to have a very business logic-y orchard and a dumber middleware layer (no calls to two libs and if-this-then-that). Starting from info for now. If at any point you start not liking this please stop me ok 😃 it will take a bit of time but I think is worth it - wow this message had numerous grammar mistakes

❤️ 4

@richiardiandrea Yeah, definitely this is worth it.


Looking forward to seeing some of the results!


FWIW I’m all for the cider-inspector growing some REBL/datafy/nav capabilities; that would be fantastic!! But I think there are still lots of use cases for which a separate sidecar UI makes sense. An obvious thing tools like REBL could easily offer that emacs would struggle a little with are the charting functions and more graphical things. Also REBL and/or an opensource equivalent may grow in capabilities too and evolve faster than one in elisp; simply because it could be a tool used by all clojure IDE’s/editors.

💯 4

> An obvious thing tools like REBL could easily offer that emacs would struggle a little with are the charting functions and more graphical things.


But you can say the same for REBL - most people simply use charting tools directly to visualize data. 🙂


That’s why this charting functionality doesn’t make that much sense to me - yeah, it’s somewhat useful, but it’s not like it’s not available today as well.


I think the power is in ease. Lack of context switching, not having to manage a lot of dependencies, etc.


@bozhidar currently yes… but if something like REBL gained traction, or if REBL became extensible in renderers then I think these expectations might change. REBL has a nice, though not unique, idea in it about using specs to dispatch and find available renderers… and Stu mentions things like REBL remembering context and picking the last renderer you used in a given context etc. Having tooling built into the RE(P|B)L/ workflow directly seems to me to be a useful place for these kinds of capabilities to exist…. in particular being able to extend the tool with domain/app specific renderers etc. Obviously REBL is currently crippled by not being opensource or end user extensible which might make my point somewhat moot.


Ok so I’ve been trying to knock together a basic nREBL middleware that will intercept evals and send the results to REBL… but it seems that you can only intercept requests in nrepl not responses, is that so?


I can’t intercept the requests because the :code is a string… which I can’t just read and eval because of side effects


so unless I can intercept the return value I guess I’d need to implement a new message type that would let the client send a specific evaluation directly for viewing in REBL.


Hmm. Is there something stopping us from just using tap to send data to REBL?


Not saying an nrepl middleware isn't worthwhile. I'm still trying to figure out what kind of workflow I want


Yes you can use tap> to send stuff to REBL it was one of the first things I tried last week with REBL… However rebl/inspect is a macro not a function you need to do this: (add-tap #(rebl/inspect %)) which corrupts the display of the expr form a bit in REBL


but it certainly does work


not that the expr form is that useful actually


I was hoping that rebl could listen and capture the complete repl history though; but it seems like it might not be feasible unless we can intercept the results of eval somehow


did you get any further with this by any chance?


I'd like to try the same


A little… In a meeting just now though.


Adding it as a special op seems to work though… I just need to figure out how to get emacs to send the op… should be pretty easy once I find the right function… I’m guessing it’ll be in nrepl-client.el


ok looks like it’s nrepl-send-request


I’d actually quite like to integrate REBL with scope-capture and emacs; so I think perhaps a middleware might be the best way to do that