Thank you for feedback! I think I just got used to that, but now that you brought my attention to it, I agree — cursor should follow the navigation more. I’ll think about that

Yes, structural navigation is the next thing I’m planning to work on

Good point about troubles with escaping in jvm-opts, I’ll investigate other ways to supply configuration

there is datafy action available for objects if their datafication is different from the initial object (e.g. vars)

How does it detect "different"? I'm not getting the right result from Reveal's datafy for a JDBC Connection object -- it seems to do object reflection, whereas if I explicitly call datafy on it, I get the right thing (the protocol implementation from next.jdbc.datafy).

https://www.dropbox.com/s/g4hzw157mojyv00/Screen%20Shot%202020-09-17%20at%201.20.26%20AM.png?dl=0 If I use Reveal's datafy option, I get the result panel shown but if I call datafy directly, I get the hash map with :schema, :closed etc (shown in the output panel, below the connection object).

As a follow-up, here's a screen cap of the inline results in Atom, showing the two evals that were tap>'d into Reveal for the screenshot above: https://www.dropbox.com/s/7rgswf2118weo2t/Screen%20Shot%202020-09-17%20at%201.22.38%20AM.png?dl=0

You are datafying a class in a first screenshot

select #object[

I'm datafying a class explicitly for the hash map result shown tho'

Oh... OK, let me try. It seemed to jump over that...

Bingo! OK, that works. I'll have to watch for that...

If I have the cursor as shown here https://www.dropbox.com/s/oczgayt1tho9j9z/Screen%20Shot%202020-09-17%20at%201.34.51%20AM.png?dl=0 and I cursor down, I end up on the classname, not the object which was confusing.

If, instead, I use cursor right, I end up on tap> which seems kind of pointless, then cursor right and I end up on #object[ and then I can datafy it.

Yeah, I really should start working on structural navigation ASAP...

I'd probably be a lot less confused with that 🙂

What about the second half of my comment -- about automatically displaying a result as a table if applicable without needing to switch from the editor to Reveal, navigate to the last tap>'d value, pressing space, selecting view:table, and pressing return, and then switching back to the editor?

(it would need to be a transient result tab that was updated with each new tap>'d result)

what do you mean by showing results as table? the table that gets a new row on every tap>?

or replace the whole table contents with rows/columns from the latest tapped value?

I mean a shortcut that basically does view:table automatically (if applicable) for every new result.

Which is what REBL does, essentially.

But it would be a temporary tab that would go away as soon as the next result came along. Which in turn would create a new tab for view:table if it was applicable.

In other words, for every result that could have view:table applied, do it automatically. It could be a mode selected via a JVM option -- it wouldn't have to be the default. Maybe :auto-table true in the prefs?

And the new tab created with the table view would automatically close (or just be replaced) as each new result came in.

hmm, good idea, I’ll think about that!

many thanks for your feedback!

That's probably the #1 usability issue for me, coming from REBL.

and your need applies to tap only, or to everything submitted to reveal?

I think "everything submitted to Reveal" makes sense -- since REBL does this for REPL values as well as submitted values.

I just confirmed datafy on namespaces is very usable. Slightly more work than REBL (again, the auto-table view thing) but acceptable.

(ok, I'm off to bed)

I hear you 🙂 I agree, Reveal requires more work to use than REBL because of it’s approach to inspection as an open set of actions, and some sort of automation would benefit it.

Good night!

@U04V70XH6 I made a new release — 1.0.130 — that fixes a bug with reveal's table view that I found while prototyping something that might be useful to you. With that version, you can evaluate the following:

(require '[vlaaad.reveal.ext :as rx])

(let [last-tap (atom nil)]
  (add-tap #(reset! last-tap %))
  (rx/view-as-is
    {:fx/type rx/observable-view
     :ref last-tap
     :fn (fn [x]
           (if (or (nil? x) (string? x) (not (seqable? x)))
             {:fx/type rx/table-view
              :items [x]
              :columns [{:fn identity :header 'value}]}
             (let [head (first x)]
               {:fx/type rx/table-view
                :items x
                :columns (cond
                           (map? head) (for [k (keys head)] {:header k :fn #(get % k)})
                           (map-entry? head) [{:header 'key :fn key} {:header 'val :fn val}]
                           (indexed? head) (for [i (range (count head))] {:header i :fn #(nth % i)})
                           :else [{:header 'item :fn identity}])})))}))

How do I use it?

(i.e., after eval'ing that expression, what do I do with the view?)

after you eval it, there will be an #object[blah blah blag] in the output. Select #object[ and choose view action

then try tap> -ing stuff 🙂

Got it! Oh, that is very nice. Yes, that's pretty much exactly what I was thinking of with the "auto-table" preference!

Yeah!!! That's much more REBL-like! Thank you!

...and it's possible today using default extensibility mechanisms 🙂

And how would I automate that so it always got eval'd and "view"'d on startup of Reveal?

and that is a story for another time 🙂

I agree, some sort of automation with regards to preferred views will improve Reveal, I'm not giving up on that

Is the view option in the drop-down, something that can be called in code? (I would assume so, but don't know where to start looking for that)

do you want to trigger that action from code?

I'm not sure this is possible from the repl. You need to get a reference to the ui function and then reflectively reach event handler, and then dispatch :vlaaad.reveal.ui/execute-action event

that's, like, super implementation details 🙂

Ah, OK. Then I guess I'll wait for this to get built-in as a pref that can be triggered 🙂

(and, meanwhile, do some of it manually)

I've pasted that code into my dev.repl ns at work so at least I have it easily to hand if I restart my REPL.

In java-bean action I assume? I’ll have a look if there is a good way to avoid these warnings without compromising the ability to inspect objects…

I haven't been using java-bean in the drop-down so I'm not sure what is causing it.

ah, that’s interesting…