@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!)
I’m 100% with you
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..
so it would magically look like:
;; foo
;; bar
[1 2 3 4]
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!