Fixes https://github.com/sbt/sbt/issues/5206
Problem
--------
Coursier uses directories-jvm to determine its default cache directory.
Currently directories-jvm shells out to Powershell to call the [Known Folders API](https://docs.microsoft.com/en-us/windows/win32/shell/knownfolderid), which doesn't work in various environments, and instead of an error, it apparently returns `null/Coursier/cache` as the directory name.
Solution
--------
With due respect to the heroic effort directories-jvm is making to comply to the directory standards on all operating systems, including that of Microsoft, I don't think the majority of the sbt users care exactly where that directory is as long as it is well-documented, and calculated in a fast and predictable way.
Instead of shelling out to Powershell, or using JNI, to hit the Known Folders API, I propose we first look at `LOCALAPPDATA` environment variable. When it is not found, it will fall back to `$HOME/AppData/Local`. Per discussion in https://github.com/dirs-dev/directories-jvm/issues/43, `LOCALAPPDATA` environment variable may NOT represent the one-true Known Folders API value of the AppData directory in case the user happened to have set the `LOCALAPPDATA` environmental variable. For the purpose of picking a directory for Coursier cache, I don't find that to be a problem because it will be faster, more reliable, and predictable.
The processing log is sent when a command issued by a request is being
processed, if the request has not yet been responded. In particular,
the processing log of sbtReportResult is filtered out if the client has
already received a response.
The processing log severity is the lowest so that it can be ignored by
the BSP client.
Fixes https://github.com/sbt/sbt/issues/6372
sbt 1.4.x includes both JLine 2 and JLine 3, and our fork of JLine 2 uses JAnsi matching with JLine 3.
I need to bump JLine 2 together, which uses the same JAnsi version as
JLine 3.
The inputFileChanges, inputFiles and outputFiles macros all used the now
deprecated `in` syntax, which causes warnings for builds that use these
apis. SlashSyntax doesn't naively work in these macros so it was easier
to just reimplement the logic in this file.
Fixes#6330
Fixes https://github.com/sbt/sbt/issues/6348
Intentionally or unintentionally the JLine 3 leaks over from sbt to
Scala REPL currently.
I think this enables things like sbtn to transmit tab completion and
other console interaction over a socket to sbt server.
Scala 2.13.5 REPL now causes some issue of displaying warning
each time the user hits tab for tab completion.
This works around the issue by upgrading to the latest JLine 3.
eugene yokota
Arthur Sengileyev
Adrien Piquerez
dependabot[bot]
Ethan Atkins
Matthias Kurz
Ondra Pelech
Marcos Pereira
Jason Pickens