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
REPL Ctrl-C behaviour suggestion #6302
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6302?orig=1 |
Chip Senkbeil (senkwich) said: Like the description says, you could rewrite looping constructs to be interruptible, but that doesn't do anything for external code being referenced inside the REPL. Just seems like something that would be nice to have, but maybe it's too much to ask for. |
@paulp said: |
Chip Senkbeil (senkwich) said: In JDK 7, this was what I found when browsing JDK 1.7:
|
@paulp said: |
Li Haoyi (lihaoyi) said: [info] Running ammonite.repl.Repl
Loading Ammonite Repl...
@ while(true) ()
Interrupted!
@ |
Hey guys 👋, it's 2019 and this still hasn't been addressed yet. Seems like Alex's proposed behavior for |
@vegerot no one has submitted a pull request |
@vegerot @SethTisue See also recent discussion here: https://users.scala-lang.org/t/c-ctrl-c-closes-repl-expression-interpreter-interactive-loop/7187/13 I just made this feature suggestion for the Scala 3 REPL here: |
From my scala-internals post (https://groups.google.com/d/msg/scala-internals/PqK6GkZhJK0/xjZw3wQ4wYEJ), verbatim:
Ideally, the function of Ctrl-C should depend on whether the REPL is waiting for user input, or running something in the foreground.
Waiting at a prompt, my preference would be:
With a foreground task running, ideally Ctrl-C should kill the task and return control to the REPL. I guess this implies running each command in a separate thread from the REPL itself, so it can be forcibly stopped—but of course, this doesn't necessarily imply starting a new thread for each command—we could just keep one of them around to run user code in—until it dies, only then we start a new one.
As for the mechanics of stopping the task, so long as we're baking pie in the sky...
If anything is running in the background, may FSM have mercy on its soul. Out of scope. :)
If we felt like being clever, we could rewrite any line that has a looping construct at the root of its tree to be breakable. If it's a method call that loops, well, too bad.
The text was updated successfully, but these errors were encountered: