My peeking and poking around has led me to find *print-fn*, and I see that I can override that myself if I want. So I am trying out that approach.

So a little Google searching led me to find the existence of process.stdout object in Node.js, which has a write method that can take strings.

I write this function, full of hope that it is on the way to my dream:

(defn write-multiple-strings [& strings]
  (doseq [s strings]
    (.write js/process.stdout s)))

And when I evaluate this (write-multiple-strings "foo" "bar" "baz" "guh"), I get a very odd printed result:

foo
barbazguh

It seems that no matter how many arguments I call write-multiple-strings with, the first string is printed, then a newline, then the other strings are printed without a newline after them. I just don't even know how to make sense of that yet.

It is somehow as if something in the implementation of process.stdout write method knows whether I am going to call it again from within write-multiple-strings? I would gladly pay $10 for someone to explain this behavior, because it will easily cause me that much time of wondering.

More data -- it behaves weirdly as described above when I am running over a socket REPL from inside of Emacs inf-clojure so perhaps something in that stack is messing with things.

When I start a Node-based REPL from a terminal with this command, no newline is injected in the middle: clj -Sdeps "{:deps {org.clojure/clojurescript {:mvn/version \"1.10.520\"}}}" -m cljs.main --repl-env node

OK, and when I use telnet to connect to the Node-based REPL, without Emacs or inf-clojure involved, also looks good (no extra funky newline)

So this looks like it is probably something strange in inf-clojure, probably.

Shaving 1 yak is enough for now. I will not attempt to also shave the inf-clojure yak today (or probably ever)

Hey Andy, I think this is a long-standing issue with the Node REPL…

Issue, as in you wish ClojureScript out of the box behaved differently?

It even occurs with the “plain” supported setup of

clj -m cljs.main -re node

I think I fought with this one in the past… I wonder if it led to a JIRA or I found a good reason to give up.

I have an alternate definition of function enable-util-print! in file src/main/cljs/cljs/nodejs.cljs that looks like it will do better in this regard, if you are interested.

Although I do not know how stable it is across different versions of Node.js -- it uses (.write js/process.stdout s) to write strings without a newline.

The maybe-enable-print! stuff near the bottom of cljs.core might be relevant as well.

It probably takes the (exists? js/console) cond branch.

Maybe a branch would need to be added prior to that one for *target* "nodejs" that sets up a better print facility.

lumo is Node-based and somehow gets this right 🙂

I am learning from your description of the dizzying variety of environments available. 🙂

Welcome to ClojureScript 🙂

ClojureScript has reach, which is usually thought of as a good thing 🙂

I am not sure if I have the activation energy required to try out proposed changes for all of these environments, but am definitely happy to try out a variant or two for a Node-based REPL. I suspect that is a drop in the bucket compared to what needs to be tested, though.

Would it be more help than busy-work for you if I tried out a variant with a new cond case for *target* "nodejs" in maybe-enable-print!, that seemed to work for me?

What scares me is things like re-natal which is for building React Native mobile apps, which ends up using this Node-based bundler process, and re-natal specifically sets the *target* to Node, which I now think of as an abuse, even though I wrote about it in https://blog.fikesfarm.com/posts/2017-07-17-cleaner-clojurescript-react-native-interop.html

In short, it is nearly impossible to come up with a perfect answer for all of these strange environments. I would suggest it is OK to limit consideration to the shipping Node REPL, and let time prove whether any given patch suffices for non-shipping environments.

In other words, I’d try seeing if *target* "nodejs" in maybe-enable-print! flys.

Understood. I have a solution that I am happy monkey-patching *print-fn* for my local dev. If you'd like a patch that relies upon (.write js/process.stdout s) for *target* "nodejs", that sounds easy for me to cook one up, but again, not sure if it helps.

Looks like I might learn how to build ClojureScript from source today 🙂

Oh, cool. 🙂

FWIW, you don’t actually have to build it. You can use it as a :local/root or even a :git/url dep.

So one dev workflow is to make a change, and then test it by specifying ClojureScript as a :local/root dep.

ok, will give that a shot first. thx

Well, I definitely know :local/root is working after accidentally introducing a syntax error 🙂

At least in my Node-based REPL, the fn maybe-enable-print! is called with *target* bound to "default", not "nodejs"

That is the case regardless of whether I create a Node-based socket REPL, or use -m cljs.main --repl-env node when starting ClojureScript REPL from a terminal command.

BTW, Clojure atoms for the debug logging win, when messing with how print functions work 🙂

Thanks for the help and suggestions, @U04VDQDDY. I turned them into a proposed patch for ClojureScript: https://clojure.atlassian.net/projects/CLJS/issues/CLJS-3153 The patch might be inadvisable for all kinds of reasons I do not know yet, so don't hold back on suggesting alternatives, if you think of any.

Cool!