Errors shown in OUTPUT Panel with stacktrace

[fasfsfgs]

Instead of using the PROBLEMS Panel, we use now the OUTPUT Panel to show errors raised during eval. It shows the error message with the stacktrace as well.

This closes #28 and closes #4.

[avli]

Thank you for the pull request, @fasfsfgs

While playing with your code I spotted a bug with the output. Here are the steps to reproduce:

1. Connect to nREPL.
2. Open an empty Clojure module.
3. Add the following code: (foo 1 2 3) (suppose the foo function is undefined).
4. Run the Eval and show the result command.

The result is something unexpected:

Could you fix this before I merge your changes?

[fasfsfgs]

My testing skills sucks. =(

Can you specify better what do you mean by:

2. Open an empty Clojure module.

I was unable to reproduce. I open an empty file and it shows the following on my console:

clojure.lang.Compiler$CompilerException java.lang.RuntimeException: Unable to resolve symbol: foo in this context
 at Untitled-1:1:0
    clojure.lang.Compiler.analyze (Compiler.java:6688)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$InvokeExpr.parse (Compiler.java:3766)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6870)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
    clojure.lang.Compiler$FnMethod.parse (Compiler.java:5380)
    clojure.lang.Compiler$FnExpr.parse (Compiler.java:3972)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6866)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.eval (Compiler.java:6924)
    clojure.lang.Compiler.load (Compiler.java:7379)
    clojure.lang.Compiler.eval (Compiler.java:6927)
    clojure.lang.Compiler.eval (Compiler.java:6890)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__648.invoke (interruptible_eval.clj:87)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invokeStatic (interruptible_eval.clj:85)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:55)
    clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__693$fn__696.invoke (interruptible_eval.clj:222)
    clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__688.invoke (interruptible_eval.clj:190)

[avli]

Sorry, I wasn't clear enough. Just open a file and save it with the .clj suffix and add the code snippet I suggested above – that's what I mean.

[fasfsfgs]

@avli I was unable to reproduce this bug with the correct configuration.

But I found out it happens when you don't have cider-repl dependency in your profiles.clj.

Do you have this configuration set when trying out this PR? Maybe you deleted that to work on your embedded-nrepl branch. Can you verify that please?

[avli]

You're right, I don't have cider-nrepl in my dependencies. I'm wondering if we should notify a user explicitly about missing dependencies?

[fasfsfgs]

Yup. I thought about that as well. Can we make this another issue or do you want me to try to add this behavior here?

[avli]

Sure thing, let's do it this way!

[fasfsfgs]

Which way? =p

1. merge this pr and create another issue to handle unmet dependencies
2. handle unmet dependencies in this pr

I'm more in favor of 1. since we can do a more broad work on it in the other issue and we are working to get hid of those deps anyway.
But if you like 2., we can discuss more here what should happen when someone tries to connect to the repl without the dependencies.

[avli]

I agree with you – let's stick with the first option. If you don't want to do any changes in this pull request I'll check it once again and merge it.

[fasfsfgs]

Alright I have nothing to add to this PR then.

Please merge it (and publish if you feel comfortable) to close #4 and #28.

I reported #31 to handle undeclared dependencies and I'll work on it next.