Send stderr output to the REPL buffer.

[pjstadig]

Reflection warnings are sent to stderr, and are currently displayed in
the minibuffer (though you can't actually see them there because they
get scrolled out of view). They used to be displayed in the REPL, and
it is more helpful to have them displayed there.

[bbatsov]

I'll have to think about this. Clearly the current situation is suboptiomal, but on the other hand it seems odd to send to the REPL output from code that wasn't executed there. I was thinking at some point that maybe we need some extra buffer like cider-output for output generated from interactive evaluations.

[pjstadig]

Not sure what you mean. Currently when you compile a buffer its stdout is sent to the REPL buffer. This change just makes it also send the stderr to the REPL buffer. Unless you are thinking that stdout shouldn't be sent to the REPL buffer either?

When compiling I think of it as sending the code in the buffer to the nREPL server, so it doesn't seem weird to me that the output should show up in the REPL. Perhaps having some kind of a pop up buffer with the output is a way to do it, but I don't think I'd like that solution.

I guess in my mind I imagine working with a organic program that you're creating incrementally. Lines in a file are evaluated one at a time with REPL semantics, so it isn't confusing to me to see output in the REPL.

[bbatsov]

Not sure what you mean. Currently when you compile a buffer its stdout is sent to the REPL buffer. This change just makes it also send the stderr to the REPL buffer. Unless you are thinking that stdout shouldn't be sent to the REPL buffer either?

I'm well aware what your change does, but as you guessed I'm not sure that the output from every REPL interaction should go to the REPL buffer.

When compiling I think of it as sending the code in the buffer to the nREPL server, so it doesn't seem weird to me that the output should show up in the REPL. Perhaps having some kind of a pop up buffer with the output is a way to do it, but I don't think I'd like that solution.

SLIME started the trend you describe and I guess a lot of people are used to this behaviour, but I don't think it's ideal to pile a lot of output without any context what-so-ever in the REPL buffer all the time. And there's also the fact that the REPL buffer is not the same thing as the underlying "REPL"... I understand your reasoning, believe me, but I'm not sure what you propose is actually an improvement (at least not for everyone). There's also the fact that due to something I haven't had the time to debug, displaying a lot of output in the REPL buffer degrades in performance quite a lot (#228).

I guess it might be best to rework this to be configurable. I think on this a bit more.

Btw, @gtrak @jeffvalk @technomancy @hugoduncan I'd love to hear what you think regarding this (rather broad) issue.

[jeffvalk]

I, for one, really don't like my REPL buffer filling up with output/errors that didn't come from REPL evaluation. To me, it's a signal-to-noise issue.

@bbatsov I like your idea about having a separate output buffer. I also see @pjstadig's point about all evaluation really being through the same pipe and treating returned output as such, though I would not want that to be the default. A flag to direct output to the REPL instead of the output buffer seems a good option.

[pjstadig]

"but I don't think it's ideal to pile a lot of output"

FWIW, unless you have a lot of side effects in your top level forms the only things you should see showing up in the REPL buffer (as a result of compiling) are errors and things like reflection warnings. Neither of which seems like something you'd want to miss.

I guess the argument could go both ways. For a small amount of output either an output buffer or putting it in the REPL seem reasonable. However, like I said, I tend to think of my Clojure process as a single organic system and the REPL my window into it, so it would be weird to have output going to different buffers.

[jeffvalk]

@pjstadig Compiler errors popup the error/stacktrace buffer, and highlight the error location -- this is already pretty hard to miss. Similarly, compiler warnings (e.g. reflection) are highlighted in the source. The latter is admittedly not as prominent, but type hinting is an optimization that really ought be applied as needed, not mandatorily on every compile.

I'm sympathetic to your desire for an organic feeling environment, but I don't think compiler errors/warnings are a strong example for the argument you're making. Personally, while I'd like to see as much flexibility as possible in CIDER, I'm sceptical of reading unstructured text as productivity enhancement.

[pjstadig]

Honestly I had forgotten that the compiler warnings were highlighted in the code. :$

There is another gap though, and that's warnings about vars that have already been imported, like so:

WARNING: symbol? already refers to: #'clojure.core/symbol? in namespace: sybilant.types, being replaced by: #'sybilant.types/symbol?

These currently get swallowed in the *Messages* buffer with no indication except that the minibuffer has some extra blank lines as it tries to show multiple lines of text.

Again, I think the most natural way to think of the REPL buffer is as if you were running lein repl at a terminal. You'd expect to see outs and errs showing up in your terminal, not being swallowed up. However, I'd be fine with splitting the output into separate buffers at some point as long as it was consistent.

Currently it is not consistent, it is swallowing some messages that are useful to see, and this is a one line change.

Can we merge this in and sort out some of these design issues afterwards?

What are the downsides to merging this in? Would it break things? Would it cause behavior that would be more surprising to users than what is currently happening?

[bbatsov]

Again, I think the most natural way to think of the REPL buffer is as if you were running lein repl at a terminal.

That would imply that the relevant expressions that produced output, errors, whatever should be in the REPL buffer as well.

Can we merge this in and sort out some of these design issues afterwards?

Obviously not everyone is in favour of this change, so no. We should take into account everyone with reasonable preferences. It's in my pipeline to make this configurable, hopefully I'll get to doing this sooner rather than later.

[cch1]

I sure wish this would get addressed. A separate buffer for the REPL process' stdout & stderr would be ideal. My use case (in addition to the ones mentioned by @pjstadig) is logging: logback and log4j are frequently configured with a ConsoleAppender and that logging is now unavailable. Reconfiguring logging to send to a file is one option -but it is clunky to do so only for the repl.

Please provide buffers for the repl process' stdout/stderr.

[bbatsov]

What you're asking for is pretty different from the original ticket. Perhaps you should file a new ticket.

[Malabarba]

FWIW, I'm fine with this PR. The REPL is the first place (and frequently only) place where a lot of people look for feedback. My only fear is that seeing compilation warnings on the REPL might cause people to pay even less attention to the cider startup warnings (which is already a problem we have).

As for having a dedicated buffer, that's fine too. It should definitely use compilation-mode so that we can leverage its automated highlighting and other functionality.

[bbatsov]

Btw, I'm guessing everyone is aware of

cider/cider-interaction.el

Line 198 in a439429

(defcustom cider-interactive-eval-output-destination 'repl-buffer

[bbatsov]

As for output generation in general - it was often discussed to be able to redirect output/stderr using a regular expression. People would just have to define mappings regexp -> buffer-name. Something like this would be pretty simple to setup.

[cch1]

A regexp to redirect the repl process' stdout/stderr to a named buffer would easily address my outstanding use case of log4j ConsoleAppender log messages.

Such a feature would be awesome.

[bbatsov]

I've created a ticket for this #1525