Closed LadyCailin closed 3 years ago
Can you SSH into the server and run locale charmap
and then do the same when just in the WSL terminal?
This is caused when there is a mismatch in character encoding between the client and the server. As for mouse integration not working, not sure how you could fix that.
I use Putty + WinSCP for all my minecraft server admin work and I've only had the character encoding issue once on a server box I had that didn't have the correct encoding set. (Both should be UTF-8)
Locally, it's UTF-8, but on the server it's ISO-8859-1. Not sure how to change that.
I suppose supporting windows terminal/cmd would be a feature request, but that's not what I'm after here, I'm mostly interested in getting it to work with WSL.
You could try this: /usr/sbin/update-locale LANG=en_US.UTF-8
though I'm not sure if that works or not as it's been ages since I fixed this issue on my end.
As for adding WSL click support, not sure if that's something we can really do. The codebase is pretty outdated and in dire need of a port to newer python versions (currently running python 2.7).
Sorry, to be clear, clicking works with WSL, it's just the display that's wrong.
Anyways, I set my LANG to en_US.UTF-8, and locale charmap returns UTF-8 now, and it's a lot better, however, there's still a column of ? blocks on the left margin.
Any ideas on this?
I'm not sure what would cause that, I've not experienced that issue before. Usually stuff like that is character encoding related, but in this case clearly not. I wonder if urwid uses a special character that the windows terminal cannot display?
My friend also uses the WSL and also has this character issue, I've recently updated mark2 to work with python 3. Mind giving it a go to see if it's still present? Not sure what else I could do it if is still present after that. You will need to reinstall the dependencies for python 3 following the updated install guide
I was able to take a peek at what the actual console characters would be by piping the console output to a file and I noticed the sides are lined with the unicode characters to (I assume) set the console colors ([0;39;49m
being at the start of every line)
For example, that unknown character you see in your console and as you see it here too, is actually this:
This is probably a character your terminal cannot display and uses that question mark box whereas the terminal I use probably just ignores it.
AFAIK this is not something we can fix on mark2's end
My suspicions are correct, urwid uses the characters I see in the output as internal characters for setting colors and such. This is the escape character and is the first character in the above message, and the one at the end of each line is here. Just unicode characters your console can't display that's all
I see. Well, thanks for the help anyways, getting rid of the rest of the problems makes it much easier to read at least.
I tried out WSL and I too experience the problem you have, I've also noticed the right side of the screen is cutoff (serve?)
Ah it seems urwid is aware of this: https://github.com/urwid/urwid/issues/264
So, as a workaround, I've figured out that if you use Windows Terminal with a WSL window, everything works completely as expected.
Using WSL/Ubuntu 20.04 to ssh into the server, then running mark2 attach displays this:
Interestingly, using the new Windows Terminal works just fine in displaying, but the mouse integration doesn't work, whereas the borders are displayed wrong in WSL, but the mouse integration works. Neither works in cmd.exe, the screen is completely unusable in a PowerShell window.
$TERM is xterm-256color in all cases, including in the WSL window.
I know Windows isn't supported, but I presume that's on the server side? Anyways, not really sure if this is considered a bug or a feature request, but either way, it would be nice if this worked.