New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enable -Djline.sigcont by default in repl (so it can be suspended and resumed) #1416
Comments
Imported From: https://issues.scala-lang.org/browse/SI-1416?orig=1
|
Geoffrey Alan Washburn (washburn) said: |
@paulp said: |
Geoffrey Alan Washburn (washburn) said: It might be better to contact the JLine people first and see what they think about the problem, because I am inclined to believe that this is a bug in their code. Incidentally, I just noticed that this does not seem to be a problem under Linux, but I can reproduce the problem on MacOS X. |
@paulp said: What's a little uncool here is why the JVM doesn't specify the behavior, given that as far as I know you can't manipulate signals from java without JNI. If I had to pick a villain I'd go with apple's red-headed JVM. Best I can do for the time being is attached, which confirms the exception message is exactly the one I get on OSX. Won't win any generality awards but should be unlikely to do any harm, and might solve the issue for all mac users. |
@paulp said: |
Geoffrey Alan Washburn (washburn) said: |
@paulp said: |
Geoffrey Alan Washburn (washburn) said: |
@paulp said: |
@paulp said: |
@adriaanm said: |
is this still an issue in JLine 3? our JLine 3 upgrade (scala/scala#8036) will land soon, so it's only worth thinking about in that context |
is this even still an issue in JLine 2? I was not able to reproduce the problem in any Scala version I tried (going back to 2.7.x) just now, on MacOS |
Maybe of relevance: |
on Gitter, @nogurenn says he isn't available to reproduce it either (on MacOS). we can reopen the ticket if anyone can confirm that the problem still exists on any modern setup my informal impression is that people used to complain about this but I haven't heard a complaint about it in ages |
Ctrl-Z on the interpreter is effectively the same as Ctrl-C because jline throws an uncaught java.io.IOException when the job is resumed. This is a huge bummer when one has work in progress in the interpreter. Attached patch catches and discards the exception; ctrl-C and ctrl-D still exit the interpreter.
The text was updated successfully, but these errors were encountered: