Fork me on GitHub
#cider
<
2017-01-28
>
agile_geek08:01:04

@jr0cket thanks for the info. I've seen other issues around 25.1 so I don't want to go there just yet anyway.

qqq16:01:42

I've written my own helm via (helm ... ), however, the only "action" I have available is "identity" -- how do I get other actions ?

qqq16:01:52

or rather, how do I implement other actions?

qqq16:01:01

answer: :action

dpsutton17:01:13

@bozhidar i'm starting to think that the notion of mapping functions across connections is hopeless. The reason so is that so many things reach out to the current connection. For instance, suppose we move all of the connection resolution to just the top level entrance, (eg. eval, info, doc, etc). These things could map across connections and the connection is passed to all of the layers of code between the keypress and eventually the cider-nrepl function that bencodes and sends to the process. Unfortunately, any and all of these can trigger errors so a stacktrace can pop up. The stacktrace has a function cider-stacktrace-navigate that feels free to ask for var info, and therefore needs to know which connection it should ask for var info. Therefor, if we mapped the same info across clj and cljs connections and one or both threw an error, this navigation wouldn't know to which function to reach out

dpsutton17:01:29

my guess is that we make it easy for buffers to set a preference out of many connections and do this

dpsutton17:01:51

therefore when handlers like this are required, at least there is a deterministic connection for them to consult

richiardiandrea17:01:34

I know zero about the problem but what if all the functions return a map: `{:result ... :exception ... :buffer or buffer-id` Then you could compose easily and even map (asynchronously) over the side effecting functions Maybe it is no doable, but I found when I was implementing replumb that this approach is very flexible (I could not use core.async) and easy to read

dpsutton18:01:28

I'm not sure I understand