This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (286)
- # aws (3)
- # beginners (243)
- # calva (4)
- # cider (51)
- # cljs-dev (8)
- # clojure (74)
- # clojure-conj (1)
- # clojure-france (1)
- # clojure-italy (1)
- # clojure-spec (21)
- # clojure-uk (22)
- # clojurescript (25)
- # clojurex (6)
- # code-reviews (5)
- # core-async (3)
- # cursive (1)
- # defnpodcast (1)
- # fulcro (29)
- # mount (1)
- # off-topic (85)
- # onyx (5)
- # other-languages (7)
- # pathom (6)
- # pedestal (6)
- # re-frame (20)
- # reagent (2)
- # reitit (8)
- # ring-swagger (10)
- # shadow-cljs (53)
- # spacemacs (8)
- # tools-deps (34)
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
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
@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
nav with nREPL, though.
Don't they? Even if it's convenient to launch, and offers a superior UI? Interesting.
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
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”
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? 😅
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 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
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.
> 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
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.
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
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
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