Fork me on GitHub
#klipse
<
2016-11-02
>
jrheard14:11:55

@viebel - i’m awake!

jrheard14:11:43

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!

Yehonathan Sharvit14:11:05

I don’t like the prompt at all from a ui perspective

Yehonathan Sharvit14:11:24

But that’s the only trick I found to be able to synchronously query the user

Yehonathan Sharvit14:11:04

And I think it’s important to allow the user to say - “don’t kill the loop"

jrheard14:11:09

ah, gotcha

jrheard14:11:52

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

jrheard14:11:21

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

jrheard14:11:04

ok, well that’s a good point - i’m less opposed to the prompt than i was before 🙂

jrheard14:11:49

we could also use (js/confirm) so they have yes/no buttons instead of having to type in “yes” or “no"

Yehonathan Sharvit14:11:41

The reason I chose prompt is that I thought there might me - in the future - more than two options

Yehonathan Sharvit14:11:54

maybe - store code in localStorage

jrheard14:11:55

ah, interesting

Yehonathan Sharvit14:11:58

or - refresh the page

jrheard14:11:12

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?

jrheard14:11:27

(unless you plan on adding support for more options in this branch, in which case i think sticking with the prompt is fine!)

Yehonathan Sharvit14:11:01

I’m 100% with you

Yehonathan Sharvit14:11:08

it’s the essence of agility

Yehonathan Sharvit14:11:21

don’t prepare for something that might never happen

jrheard14:11:47

it’s exciting that this feature is actually working!

jrheard14:11:56

i didn’t think it’d be possible to fix it so quickly!

Yehonathan Sharvit14:11:08

Yeah I am amazed too!

Yehonathan Sharvit14:11:20

I thought about it a couple of weeks ago

Yehonathan Sharvit14:11:38

I mean about the idea of preventing inf. loops

Yehonathan Sharvit14:11:55

But I put it aside as I didn’t find any simple way of doing it

Yehonathan Sharvit14:11:13

And then, a couple of days ago, you re-opened the discussion

Yehonathan Sharvit14:11:24

And it made me think about it again

Yehonathan Sharvit14:11:43

Meanwhile, I have been much less afraid of looking at cljs.compiler code

Yehonathan Sharvit14:11:57

This is how came to my mind the idea of overriding emit

Yehonathan Sharvit14:11:29

BTW, do you think there is a better way to override emit - whithout copy/pasting the whole code?

Yehonathan Sharvit14:11:55

I mean: print the guard() and then defer to the original emit

jrheard14:11:00

i haven’t been able to think of anything 😕

jrheard14:11:06

i agree that copy-pasting it doesn’t feel great

Yehonathan Sharvit14:11:24

(def original-emit emit)

Yehonathan Sharvit14:11:35

(defn my-emit
 (if .... (print “guard()”))
 (original-emit))

Yehonathan Sharvit14:11:08

But it did not work at all

jrheard14:11:10

did original-emit end up getting overriden later? maybe a defonce would help

jrheard14:11:29

or was that not the issue?

Yehonathan Sharvit14:11:30

A new feature I want to add to klipse is to append a console box to each snippet

Yehonathan Sharvit14:11:51

That will contain the output of the print statements inside the snippet

jrheard14:11:06

sounds like a good idea to me!

jrheard14:11:40

unless there’s a way to somehow prepend the output of those print statements to the preexisting output console window..

jrheard14:11:02

so it would magically look like:

;; foo
;; bar
[1 2 3 4]

jrheard14:11:08

not sure if that’s feasible

jrheard14:11:50

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

jrheard14:11:57

anyway, your call - i think that either approach (new console output window, reusing preexisting output window) is fine!

Yehonathan Sharvit14:11:44

I don’t understand what u mean by “the preexisting output console window”?

jrheard14:11:05

sorry, cat is interfering

jrheard14:11:25

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

jrheard14:11:44

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

jrheard14:11:07

in the examples i gave above, the [1 2 3 4] is what the codemirror output window would usually be showing

Yehonathan Sharvit14:11:27

much more than mine

jrheard14:11:31

hee great!

jrheard14:11:08

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

Yehonathan Sharvit14:11:59

I’m going to TAI-CHI