sbt 1.4.0 is going to ship with a native thin client that will allow for users to connect to a running sbt server process to avoid the sbt startup time without having to an sbt shell session open (https://github.com/sbt/sbt/pull/5620). As it currently stands, the console task does not work with scala 2.13 because of the hardcoded jline Terminal that is passed into scala.tools.nsc.interpreter.jline.Reader via ILoop.defaultIn. My instinct is that it won’t be possible to make the client work with 2.13.3. Off the top of my head, there are two approaches (and possibly some combination) that could work for 2.13.4 compatibility:
- Update the ILoop api so that applications could pass in a jline Terminal (this may not be ideal because then jline becomes a part of the public api of the scala compiler)
- Alter the creation of the jline Terminal that presently occurs here: https://github.com/scala/scala/blob/691f6eb732c96ac9f013aff5878c83f79c6ac507/src/repl-frontend/scala/tools/nsc/interpreter/jline/Reader.scala#L72. In sbt, there is relevant code for creating a jline Terminal that relays to the client at https://github.com/sbt/sbt/blob/b678d2115fdc1a404b3a5290a74e8db13d455855/internal/util-logging/src/main/scala/sbt/internal/util/JLine3.scala#L77. The ILoop api could possibly have a boolean toggle (or it could check for a system property) so that the scala Reader can optionally create a custom terminal that uses System.in and System.out for the input and output streams (which sbt sets during task evaluation to redirect output to the remote client) and otherwise use the default terminal builder if the flag isn’t set.
It would be somewhat disappointing if the sbt client does not work with the scala 2.13 console. In case it wasn’t clear, the console task still works from the sbt shell or in batch mode with 2.13.