Fork me on GitHub

Is there a way to access reveal's currently selected value? Sometimes I navigate into a nested value and then want to play with that from the repl (closing the reveal loop). Maybe something like *r as an analog to *1?


eg: (name *v)


that doesn't seem to work from my normal repl


it works in reveal, but I was looking for something that I could use in my editor


ah, sorry, I misunderstood the question, from REPL I dunno


but *v seems helpful in other situations :thumbsup:


one idea, what if do (def something *v) from Reveal?


just tested, it seems to def the thing under clojure.core, haha


I guess with a bit more code we can switch the ns and def somewhere else


or put an atom somewhere, and reset! that atom


I guess I could create a plug-in that does something similar


seems like having a way to “close the loop” would be generally useful

👍 3

I’ve been thinking about that before 🙂 In general it’s not possible since we usually have repls that are unaware of reveal, e.g. how would you do that with remote prepl? Eval is in different process that has no way to access Reveal… But it’s possible to create local repls that ARE aware of reveal, and maybe built-in repl could have their eval augmented to access currently selected value.


Some possibilities • maybe a function call that just asks reveal what its currently selected value is • a reveal command that sets a callback to be called whenever the currently selected value changes. Then I can use that callback to put the latest value wherever it's convenient • Since it's only for development, it might it even make sense to intern a var in clojure.core like *r that gets updated with the latest selection. This option would make it easier to share workflows


Good suggestions! One reason I haven’t done this so far (besides higher prio stuff) is because I think there might be another way to


..oops, hit enter too fast 😄

😆 3

Anyway, I think there is another issue that could be fixable with access to selection in one swoop: there is no sharing of bindings between reveal’s eval on selection and user’s repl


for example, using (prn *v) in eval-on-selection popup will print… somewhere, but not in Reveal’s UI, while using (prn :foo) with reveal-connected repl will print both to reveal and to process’ out


does reveal know what the currently selected namespace is?


nope, and this is another problem in this area


not sure it does, but if it did, then there could be an option to def a var in the current namespace


but I guess *ns* is a part of those bindings


so if/when I figure this stuff out, maybe (def foo *v) will pick a better ns than clojure.core


like user , or ns that was active when reveal repl was started, or ns from latest eval… this needs some more hammock time

👍 3

if you don't have enough options, you could also create a reveal namespace named something short like r or reveal. Then it's easy to use from the repl with r/*v , r/my-saved-val, etc.


you wouldn't even need to require the namespace since it would be fully qualified


so it would work regardless of which namespace you're working in


the main benefit is that you wouldn't have to add requires in namespaces just to access reveal values


the main downside is that short names are more likely to clash with common aliases


why not just a normal namespace like reveal.repl/*v ? Optionally other namespace / other name for *v. I woudn't consider (require '[reveal.repl :refer [*v]]) in user.clj too much of a hassle. I'm assuming it's not possible to connect multiple reveal processes? Caveat: Reveal noob, this might not make sense.


@U3X7174KS, for my personal workflow, I might be working in several different namespaces at once, so remembering to run (require '[reveal.repl :refer [*v]]) in each namespace I might be in adds enough friction that I probably wouldn't use it that often


hooking on what @U3X7174KS said, that could be a thing Reveal does, when the user changes the selection on reveal, reveal updates reveal.repl/*v (that value being an atom or something) to reflect that reference, maybe that’s what @U3X7174KS was saying


updating reveal.repl/*v makes sense. I was hoping for a shorter name for reveal.repl/*v like r/*v


@U7RJTCH6J to deal with the long names I would make a live template (aka snippet) to expand something like rv to @reveal.repl/*v