It's interesting that this request is brought up second time already...
I'll add it to reveal extensibility examples for starters :)
Hi @vlaaad Yeah, it's really the big missing piece when you compare REBL and Reveal. I'd love it to be built-in and maybe triggered by a JVM property?
Since I've had that available, I've been running Reveal full time for a week now, without feeling I need to restart my REPL with REBL enabled 🙂
Yes-yes, I'll think of a way to achieve this behavior in a more streamlined fashion
(the ideal would be if it worked for the regular Reveal REPL values as well -- but, for now, tap>
is sufficient 🙂 )
Btw, this was also the second request for remote control from clojure ;) Because I have reveal on a second monitor and I would like an Emacs shortcut for simple things like scroll to end, display as table/graph/etc, clear screen
Added tap-to-table example to the repo: https://github.com/vlaaad/reveal/blob/master/examples/e04_tap_to_table.clj
@daniel415 I have remote control in my todo list, we'll get there! 🙂
;) thanks. Love reveal so far.
I'm currently in the hammock phase for structural navigation, if anyone's curious 🙂 I thought it was a simple thing to do, but now I have 3 alternatives that I'm not certain about. Current alternatives: 1. paredit-style navigation as implemented in most editors, where the moves are "in"/"out" to enter and exit some composite data structure, and "prev"/"next" to jump between the values inside some data structures. This is the most simple navigation, but I'm not super happy with it for 2 reasons: - map navigation, which is super common, gets clunky, because I have to constantly jump between keys and their values, while most of the time I want to jump from key to key, and then select a value; - key mapping feels wrong: down arrow semantically corresponds to "in" and up arrow corresponds to "out", while the cursor movement will be horizontal, and the same with left/right arrows that semantically correspond to prev/next, while the direction in most cases will be vertical; 2. Grid-like navigation that uses all directional arrows to jump between values on the same level in data structure, e.g. when the first key is selected in a map, right arrow jumps to corresponding value, while down arrow jumps to next key. The benefit of this approach is that navigation behaves in a way I think about navigating data structures, and direction of the arrow generally corresponds to direction where the cursor will move, making it feel right. The downside is "in"/"out" type movements are harder, since all arrow keys are already taken for navigating inside the data structure. Might not be a big problem? "In" is usually just a non-structural "right" movement, and "out" can be achieved when trying to structurally navigate "left" while being at the left-most position in the data structure. 3. Another approach would be to preserve the simplicity of paredit-style navigation as in (1), but make movement "into" a map select the first entry instead of selecting the first key, so structural navigation in maps by default still jumps from key to key, at the cost of extra "in" movement necessary to go from entry to key. This is simple, and it helps with map navigation, though it adds a speed-bump by having to navigate into entry, and the shortcuts are still not intuitive. Maybe you guys have some input?
Meanwhile I'm procrastinating by building stock charts to compare companies :D
I agree that remote control everything would be a killer feature for me
Including navigation probably?
I haven't thought a ton about this but my workflow will probably involve staying in emacs without focusing on anything else. so being able to totally drive a UI from there would be cool (and conveniently compatible with all other editors as well)
This is all possible with reveal and using custom views?
Yep
Re: navigation -- two things would make Reveal easier to use from my p.o.v.: 1. if the "current cursor" automatically moved to the last character of each result as it came in 2. if there was a ctl-up/ctl-down to jump from result to result -- if you are on the last char of a result, it should move to the last char of the previous or next result; else it should move to the first char of the previous/next result
The rest of the navigation, within a result is fine as it is for me, but it's the "big jumps" from result to result that I currently find painful.
@seancorfield can you expand a bit on the last/first character? I can understand why you would want to auto-select first character — you are at the root of your data structure, but what about the last one? It's usually a bunch of closing square and curly braces in the end that are not that informative..
That's amazing. Well done!
@vlaaad Because the cursor would always be at the end of the last result, and you can do any context operations on the last closing paren/bracket that you could do on the opening paren/bracket.
I guess scrolling so it always by default on the first character of each result would be fine too but I'm using to console output always being at the "tail" of the output when it scrolls 🙂 Either way, auto-scrolling so the default focus is always on the last result is the main thing.
Yeah, I understand. Agreed. Thanks for taking time to think about it!