@viebel - i’m awake!
Good morning @jrheard
Thanks a lot for your comments on https://github.com/viebel/klipse/pull/131
np! basically the prompt just feels unpolished to me, and the codemirror output feels more polished - but it’s totally possible that i’m incorrect / crazy!
I don’t like the prompt at all from a ui perspective
oh nice
But that’s the only trick I found to be able to synchronously query the user
And I think it’s important to allow the user to say - “don’t kill the loop"
ah, gotcha
yeah, i don’t think there’s another way to query the user in this context, so i guess it’s just down to whether or not it’s important to let them decide on whether or not to kill the loop
personally, i think it’d be fine if we just always said “your thing took longer than X seconds so we killed it - try making it run faster!”, but i can see how that’s also a bad UI experience
hm
ok, well that’s a good point - i’m less opposed to the prompt than i was before 🙂
we could also use (js/confirm) so they have yes/no buttons instead of having to type in “yes” or “no"
yeah
The reason I chose prompt is that I thought there might me - in the future - more than two options
maybe - store code in localStorage
ah, interesting
or - refresh the page
or something else
that makes sense! how do you feel about going with js/confirm for now, and switching to js/prompt in the future if there ends up being support for more options?
(unless you plan on adding support for more options in this branch, in which case i think sticking with the prompt is fine!)
it’s the essence of agility
don’t prepare for something that might never happen
I love it
++
😄
it’s exciting that this feature is actually working!
i didn’t think it’d be possible to fix it so quickly!
Yeah I am amazed too!
I thought about it a couple of weeks ago
I mean about the idea of preventing inf. loops
But I put it aside as I didn’t find any simple way of doing it
And then, a couple of days ago, you re-opened the discussion
And it made me think about it again
nice!
Meanwhile, I have been much less afraid of looking at cljs.compiler code
This is how came to my mind the idea of overriding emit
BTW, do you think there is a better way to override emit - whithout copy/pasting the whole code?
I mean: print the guard() and then defer to the original emit
i haven’t been able to think of anything 😕
i agree that copy-pasting it doesn’t feel great
I tried to do
(def original-emit emit)
(defn my-emit
(if .... (print “guard()”))
(original-emit))
But it did not work at all
did original-emit end up getting overriden later? maybe a defonce would help
or was that not the issue?
Donna
Will check again
Something else
coolcool
A new feature I want to add to klipse is to append a console box to each snippet
That will contain the output of the print statements inside the snippet
Waht do u think?
sounds like a good idea to me!
unless there’s a way to somehow prepend the output of those print statements to the preexisting output console window..
not sure if that’s feasible
maybe you wouldn’t even need to prepend them, you could just interleave them like
;; foo
[1 2 3 4]
;; bar
depending on when things got printed, etcanyway, your call - i think that either approach (new console output window, reusing preexisting output window) is fine!
I don’t understand what u mean by “the preexisting output console window”?
sorry, cat is interfering
i mean that right now, klipse snippets have two windows, the input codemirror window and the output codemirror window; and it sounds like you’re planning on adding a third window
i was suggesting using the output codemirror window instead of adding a third window; but i don’t feel very strongly either way, i’m not sure which option is better than the other
in the examples i gave above, the [1 2 3 4] is what the codemirror output window would usually be showing
gotcha
I love your idea
much more than mine
hee great!
ok, breakfast time - thanks for chatting, all these features sound exciting!
I’m going to TAI-CHI
nice!