REPL test output truncated in Windows 7

[srazzaque]

Using Windows 7, when running tests in the REPL, the output will get truncated to only display the first line of output - e.g:

user> (test/some-test)
FAIL in (some-test) (some_file.clj:158)^M
;; no more output here - cannot see where the test failed :-(

(another observation is the fact that the ^M's will always appear in the output).

Strangely enough, the FIRST time you run a test in a fresh cider REPL, it does NOT truncate the output.

This also has the unfortunate result of not allowing clojure-test-run-tests to work properly.

; CIDER 0.4.0 (Clojure 1.5.1, nREPL 0.2.3)

[bbatsov]

Unfortunately I have no windows machines (real or virtual), so I can't test this myself. Is the problem present in the current 0.5 release as well?

[scottdw]

I found that the powershell inferior shell mode would interfere with the cider repl in a similar way and removing (require 'powershell) in my init files fixed it.

Regarding ^M I use a solution based on this stackoverflow answer: http://stackoverflow.com/questions/10098925/m-character-showing-in-clojure-slime-repl/11787550#11787550

[srazzaque]

Have not tried in the 0.5 release - but scottdw's solutions worked perfectly, it was indeed powershell - removing that worked.

Also addressed the ^M's in the same way.

Thanks!

[bbatsov]

@scottdw Maybe you should add this to the README in some section for Windows users?

[scottdw]

The ^M solution is a bit of kludge and I think the issue would be better addressed by setting the buffer-proccess-coding-system for cider buffers to the value returned by (.get (System/getProperties) "file.encoding") from nrepl but I'm unsure about how to go about doing that.

[scottdw]

Okay, looked a little deeper into the ^M issue. It looks like I was wrong about it being solvable with coding systems. The solution I've settled on is to add "-Dline.separator="\n"" to :jvm-opts of my :user profile in ~/.lein/profiles.clj. This has the happy side effect of fixing all of cider's buffers, not just the repl buffer (eg. doc buffers and server buffers).

Would you like a pull for the readme file with a new section under Caveats listing these two Windows issues: truncated output and carriage returns?

[bbatsov]

Yep, that sounds good to me.

[bbatsov]

@scottdw Ping :-)

[tpgit]

I believe this is a terrible idea? Changing my profiles.clj as now suggested in the Cider README now breaks lein.bat! For example, doing:

lein repl

from the command line. I get the following exception:

Exception in thread "Thread-4" java.lang.NullPointerException: key can't be null

instead of starting up a Clojure REPL. Actually, with that change I can't even run cider-jack-in, since I get the same error (although it did work a few days ago?).

After I remove that line everything works okay.

[scottdw]

I have seen this occasionally but the majority of time it Works For Me. Perhaps try running lein repl in a powershell prompt rather than a command shell prompt.

I agree that it's a "terrible" workaround, unfortunately I've tried various process-coding-system / buffer-coding-system and jvm file.encoding combinations including the utf-8-auto suggestion in #532 to fix this issue and I couldn't find a combination that worked. YMMV.

[tpgit]

At the very least the readme needs to be changed to warn users on Windows systems of how this may break lein.bat. It took me quite awhile to figure out why lein repl didn't work as the documentation describes. And I am not running the standard command prompt but the much nicer TCC/LE [1]. I don't have any particular interest in using Powershell.

Also, at least on my system, it breaks the emacs cider-jack-in command which reports the same exception? Here is my profiles.clj that doesn't work:

{:user
 {
  :java-cmd "C:\\Program Files (x86)\\Java\\jdk1.7.0_51\\bin\\java.exe"
  :jvm-opts ["-Dline.separator=\"\n\""]
  :plugins [
            ]}
 }

I tried with and without the [] around the jvm-opts. Didn't make a difference. And if it breaks cider-jack-in then this cure is worse than the disease.

Cider 0.5.0
GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
Leiningen 2.3.4 on Java 1.7.0_51 Java HotSpot(TM) Client VM
Windows 7 64bit

[1] http://jpsoft.com/tccle-cmd-replacement.html

[tpgit]

A much better idea is to follow the advice in "Hiding ^M in emacs" [1]. Put the following in your init file:

(defun remove-dos-eol ()
  "Do not show ^M in files containing mixed UNIX and DOS line endings."
  (interactive)

  (setq buffer-display-table (make-display-table))
  (aset buffer-display-table ?\^M []))
(add-hook 'cider-repl-mode-hook 'remove-dos-eol)
(add-hook 'text-mode-hook 'remove-dos-eol) ;If you are annoyed by trailing ^M in text buffers.

This fixes the trailing ^M problem at least.

[1] http://stackoverflow.com/a/750933

[scottdw]

Which is presented as the first option in the readme linking to a stackoverflow answer that references the above answer and describes how to add that function to the cider repl hook.

[tpgit]

I just re-read Caveats > Microsoft Windows paragraph of the README. It contains no reference to the possible bad consequences of setting the JVM options as described. Probably because I was reading it so fast, I completely missed the "correct" option (and the fact that the fix isn't spelled out but "hidden" inside a "here" link). [I even had to edit this response because I missed it during my 2nd & 3rd re-reads]

I repeat. The README should be changed to mention the caveats to the alternative solution. And perhaps the first fix should be spelled out explicitly, with a link to where the fix originated.

[bbatsov]

See the discussion here. It'd be great if a Windows user tested the two ideas suggested by Eli (who's an Emacs legend).

[scottdw]

I tried Eli's suggestions the other day but haven't had a chance to write up the results. By changing the process output to utf-8-dos either directly as he first suggests or by his second method (with the unnecessary cons removed) in both cider.el cider-jack-in and nrepl-client.el nrepl-connect makes the repl buffer hang after attempting to print a newline and any subsequent actions in the buffer appear to attempt to resend the message. In the messages buffer the following appears:

error in process filter: nrepl-bdecode-buffer: Cannot decode message: d2:id2:143:out6:Test 7:session36:17854520-1769-4000-b934-aab28a2bce2bed2:id2:142:ns4:user7:session36:17854520-1769-4000-b934-aab28a2bce2b5:value3:niled2:id2:147:session36:17854520-1769-4000-b934-aab28a2bce2b6:statusl4:doneee

[bbatsov]

Thanks for the info, @scottdw! I guess we're back to the drawing board regarding this.