Fork me on GitHub
#reveal
<
2021-04-07
>
phronmophobic20:04:55

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?

wilkerlucio21:04:29

eg: (name *v)

phronmophobic21:04:07

that doesn't seem to work from my normal repl

phronmophobic21:04:48

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

wilkerlucio21:04:33

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

phronmophobic21:04:49

but *v seems helpful in other situations :thumbsup:

wilkerlucio21:04:33

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

wilkerlucio21:04:07

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

wilkerlucio21:04:17

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

wilkerlucio21:04:26

or put an atom somewhere, and reset! that atom

phronmophobic21:04:06

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

phronmophobic21:04:34

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

👍 1
vlaaad07:04:04

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.

phronmophobic07:04:05

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

vlaaad07:04:28

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

vlaaad07:04:39

..oops, hit enter too fast 😄

😆 1
vlaaad07:04:23

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

vlaaad07:04:13

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

phronmophobic07:04:25

does reveal know what the currently selected namespace is?

vlaaad07:04:54

nope, and this is another problem in this area

phronmophobic07:04:10

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

vlaaad07:04:17

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

vlaaad07:04:22

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

vlaaad07:04:19

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

👍 1
phronmophobic07:04:51

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.

phronmophobic07:04:06

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

phronmophobic07:04:33

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

phronmophobic08:04:40

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

phronmophobic08:04:39

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

teodorlu20:04:53

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.

phronmophobic20:04:07

@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

wilkerlucio20:04:57

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

1
phronmophobic20:04:57

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

wilkerlucio23:04:08

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