klipse 2016-11-02

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

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"

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

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

👍 1

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

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

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, etc

anyway, 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

ok, breakfast time - thanks for chatting, all these features sound exciting!

I’m going to TAI-CHI