Writing our own main would be cool 😊

Prove the idea

Seems you’ve sorted this out by the time I came.

🙂

Btw, the built-in interactive REPL in nREPL is not really meant for any serious use, as it’s mostly a proof-of-concept (a reference for people looking to implement something on top of nREPL). We can’t really depend on REPLy or rebel, but we can always check if they are present and use them if they are. I know that’s different from the discussion, so far, but I’m mentioning it as well, as another way to get a more capable REPL client.

I want both for edge. Nrepl client in the terminal is not especially appealing for local development. Rebel doesn't have an nrepl mode.

@ackerleytng I use stump, and I handle any Ctrl-T mappings in programs by doing ctrl-t t to pass it in directly.

If I had to use ctrl-t a lot, or if I found that cumbersome, I'd probably bind a different key, such as ctrl-[ as my main modifier.

It hasn't bothered me enough yet to go about rebinding the main modifier, but that's what I did for tmux and ctrl-a (as I use readline constantly).

Weird thing: I have run cider-jack-in-clj on a project. Then, I close the connection and run cider-jack-in-clj on a second project, and this project is of type clojure-cli (deps.edn) I get the following:

This is cider-20181212.1936. No problem when running cider-18.0.

@bozhidar I've pushed out compliment 0.3.8, minus one blocker for 0.19 🙂

OK, this bothered me for a long while: if you evaluate something like this: ({:a} 1), CIDER will pop up a stacktrace saying Unmatched delimiter: ).

[dan@fedora clojure]$ clj
Clojure 1.9.0
user=> ({:a} 1)
RuntimeException Map literal must contain an even number of forms  clojure.lang.Util.runtimeException (Util.java:221)
1
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException (Util.java:221)
user=> 

[cont] I understand it is the default REPL behavior to evaluate everything until the input is exhausted, but wouldn't it make more sense to short-circuit that the first time an error happens?

Makes it a real pain in the butt to look through a large function to find that one pesky odd-element map.

do you mean this to be in #clojure-dev or here? seems like you want to change clojure?

Confusing as hell too, not to mention the beginners.

@dpsutton When that happens in regular Clojure REPL, at least you get all the errors at once. Also, it shows line/column then.

In CIDER though, only the last exception is displayed which doesn't make any sense.

Doesn't necessarily has to be a change to Clojure, might modify "eval" op as well.

ah the first error message is not shown, just the unmatched delimiter

i missed that part 🙂

AFAIU, it is probably expected for default Clojure REPL/socket REPL as it's sorta stream-oriented.

But since nREPL has a strictly defined concept of a "message", it should do no harm to discard the eval operation of the whole message at the first error.

If I recall correctly, multiple stacks are sent if available. I'm not sure what's happening to from this.

That's true, they are all sent, and I think they are actually rendered one after the other. But that happens in a rapid succession, so you only get to see the last one.

But I'd argue that the whole "read it till the end" approach is counter-intuitive and potentially dangerous.

As demonstrated in the default Clojure REPL:

user=> (defn send-rockets! [] (println "BOOM!"))
#'user/send-rockets!
user=> (comment {:a} (send-rockets!))
Syntax error reading source at (REPL:1:14).
Map literal must contain an even number of forms
BOOM!
nil
Syntax error reading source at (REPL:1:31).
Unmatched delimiter: )

> That's true, they are all sent, and I think they are actually rendered one after the other. But that happens in a rapid succession, so you only get to see the last one. Cider.el only shows one at a time, and provides no mechanism for backwards and forwards?

It does show all the lines in the REPL buffer, but only one stacktrace buffer is displayed, with the last error.