soooo...maybe it is a bit off topic here, but I am going to put it out

as @anmonteiro knows I am trying to detect the repl type in inf-clojure. There more general problem is advertise your own type. I need to do the same for a plain clj repl, a plain cljs repl, a @thheller shadow clj repl, a @thheller shadow cljs repl, @mfikes planck, ...

so I was wondering if it is a good idea to agree on a common way

a function call was my proposal but it seems it is not the best for repl devs

I am open to any proposal, the only restriction is that I will need to send text and receive text

[zilence@zpro ~/code/shadow-cljs/target]$ rlwrap nc localhost 8201
shadow-cljs - REPL - see (help), :repl/quit to exit
[104:0]~shadow.user=> (shadow/node-repl)
[104:1]~cljs.user=>

as a bit of context maybe … shadow-cljs now provides a socket-repl that you can “upgrade” to CLJS

either parsing the terminal output or the string returned on the websocket

inf-clojure needs to detect if its currently CLJ or CLJS somehow

I have a detection mechanism that works out of band

now actually I see your case is the simplest @thheller because I have a function there so from that moment on I could just switch. If shadow/node-repl returned the repl type I can just use that

actually the clue is the prompt

run (shadow.repl/level 104 1) or whatever the numbers shown are

in another connection

thats where the proper API comes it

say curl or so which would tell everything you want about that REPL 😛

but you’d need to parse the prompt

yeah I see that I could do that, but I would like to have a way that does not consider prompts because prompts in inf-clojure have weird regexes associated with them and comint kind of excludes them from the output if matching the regex

can’t you just parse whatever comes over the socket?

I have no idea how emacs does things

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/npm/client.cljs#L51-L68

this would be good:

[2:0]~shadow.user=> (shadow/node-repl)
"shadow-cljs"
[2:1]~cljs.user=>

it must be able to do something similar no?

why is that easier than parsing the prompt?

emacs is a weird beast and I am trying to define the minimal amount of changes to do in there

see above, the prompt might be parsed out

hmm ok just tell me what line to add and I’ll do that 😉

still need to double check that, but it feels complicated given my inf-clojure knowledge 😄

but the prompt would be shadow-cljs anyways .. need something that all tools support

my goal would be for repl devs to agree on a way to return that info

so let's wait for others as well ok?

for a bit of background: https://github.com/anmonteiro/lumo/issues/174

Actually https://github.com/anmonteiro/lumo/issues/111

I don’t want to start another rant about this subject

but tooling stuff should not go over the same REPL connection as the actual REPL 😛

its just painful to parse

maybe it’s a far fetched analogy but User-Agent didn’t work that well..

@cgrand didn’t you implement an edn reader that can work in node?

ie. not stream based?

(cond
  (not= (/ 1 2) 0.5) :clj
  (find-ns ‘lumo.repl) :lumo
  :else nil)

@thheller yes I did but I don’t get what you mean by “not stream based”

something I can call like (reader/next reader-state chunk-of-text) and get [next-state forms] or so

CLJ reader always blocks on read

how do you do that in CLJS?

Callbacks, what else? ;-)

hmm dammit

means you need to own whatever stream you read from right?

is that usable somewhere?

need a quick way to read EDN in a streaming fashion

(cljs.reader/read-string "{:foo") fails with EOF …

need something that I can do partial read and continue when I have more data to feed it

Can't give details now but here is the reader (search for edn-read https://github.com/cgrand/cljs-js-repl/blob/master/src/net/cgrand/cljs/js/repl/async_reader.cljs

ah thx … I’ll see it that works for what I want

And socket-reader here https://github.com/cgrand/cljs-js-repl/blob/master/src/net/cgrand/lumo/socket_repl.cljs

damn … io/*in* thats you binding thingo right?

Which bridges between a node socket and my stream abstraction.

hmm ok .. I’ll test it

Report any issues you have with it.

my main issue is the bindings but I’m too tired for this anyways

will test in the next few days

maaaan sometimes it so simple thanks @cgrand!

@thheller edn-read can accept the input stream as an explicit argument. So calling code can use it without explicit usage of dynamic binding stuff.