So, I'm using the Swift REPL from Windows with Docker WSL2 via the docker image swiftlang/swift:nightly-5.5. I run Docker with these options: --security-opt seccomp=unconfined -it --rm --name swift -e 'LC_ALL=C.UTF-8' /bin/bash
This is run from Windows 10 1903, Windows Terminal with local code page 65001, although the code page doesn't make a difference.
The environment variable setting in the docker run line means that e.g. danish characters (æ, ø, å) work correctly in the launched bash, i.e. I can cat them into files and such. They do not, however, work in the Swift REPL, started vy typing swift (or if launched directly by Docker with the command changed to swift).
Instead these characters are either completely ignored and lead to no input whatsoever, or they lead to strange things being out such as "\U+00F8", the character code for one of those letters. It's not a problem to read files containing UTF-8, using <filename, or to print such characters correctly. It's just not possible to input them. The same thing happens if I launch LLDB, so I don't know how Swift related it is (I don't know how custom the LLDB shipped in the image is).
Is this a know issue? Is it related to Linux, or perhaps Docker, perhaps when run from Windows? Thanks in advance
The Swift REPL uses a library called editline/libedit to handle the command prompt. We also set that library to run in emacs emulation mode so that the navigation/edit shortcuts work as people expect. Sadly the Linux implementation of that library has a lot of quirks regarding unicode support when running the emacs emulation mode. I don't think there is a way to disable the emacs mode that the Swift REPL is requesting (but that can be fixed).
In the meantime you can run echo "edit off" > ~/.editrc in your docker bash shell to disable libedit from being used in the Swift REPL. That will disable all edit line features (including navigating with the arrow keys), but it should allow you to type all unicode characters (and you can still edit your current expression by just using backspace to delete the last character).
Ok. With that disabled I can indeed enter e.g. an "æ" (although it allows me to backspace twice afterwards). But now the problem is that I don't proceed from the "1>" prompt, so nothing ever gets evaluated. I just get a new "1>" prompt when I press enter
