KB input on windows does not work

[ShrykeWindgrace]

Hi! Thanks for the challenge! I am rather curious about these tasks.

There is a problem with reading keyboard input on windows in the tui version of the game. The function writeUserInput is expecting a VT sequence for arrows - yet by default windows terminal (current backend for all windows-native terminals) does not send them, you need to set up stdin properly for that (in case you need more context than you would ever need to know on that subject =), there is an effort to bring brick/vty to windows here: https://github.com/jtdaugherty/vty/issues/251) TLDR: reading interactive user input on windows as VT sequences is a hassle.

Then again, if we put ourselves in a posix-like terminal (e.g. MobaXterm, it does send VT sequences for arrows), we are inviting all possible problems with io-manager =( hReady behaves rather strangely in that scenario, line buffering is not up to the task, and so on.

I propose to add `wasd/hjkl' as additional aliases for arrows, this does not break the principle of least surprise. And then

• force native io-manager as ghc rts option; should be a neutral change on linux/macos and positive on ghc-8 on windows
• skip hReady by a CPP pragma in getKey and warn the user in Readme that arrow keys would not necessarily work on windows.

Without hReady checks all characters will arrive properly one by one, and since a command is just one character, we avoid all parsing troubles.

Other alternatives would be

• migrate to haskeline (I am still not sure about arrow keys)
• implement proper windows logic to handle virtual terminal sequences (CPP pragmas, maintenance burden)
• migrate to vty/brick once there is a release for windows (ETA: unknown, this autumn at best)

Cheers!

[lsmor]

Hi thanks for the report! really appreciate it. Clearly the best approach is to use "wasd" or "hjkl" for windows users. It shouldn't be difficult to do. What I don't understand very well is the hReady part. The code has a very descriptive "In StackOverflow we trust", so I don't know very well the nuances of that function

Are you willing to contribute the change? If not, are you willing to help me testing in a windows environment?

[ShrykeWindgrace]

@lsmor Yes, I'll help with both the change and the testing. I should have some time this week for OSS.

To be honest, I do not quite understand why hReady would not work as expected in a POSIX emulator, but I hope that the number of users that build haskell in a windows-like environment and then run the binaries in a POSIX-like environment is vanishingly small.

[lsmor]

Thank you very much. I should write a contributiing file but for know keep in mind that the branches in this repo are a mess:

Long history short:

• main merges into solution-mvp which merges innto snake-fury-exercise
• solution-mvp is merged also into solution-refactor-XXX

The problem is that this only works for documentation files (README.md, refactor-x.md, etc...) but It doesn't work very nice with code files (xxx.hs).

So as a piece of advise, branch your solution from solution-mvp and PR into that branch, not the main branch which is inestable. this way we can directly merge into snake-fury-exercise so the challengers have a working software. how to deal with the rest of branches is something I can handle latter.

[ShrykeWindgrace]

Sorry for the delay - instead of doing interesting things on my vacation I spent it being sick =( The PR is still on my radar, but I can not give a good estimate on when I have time to do that.

[lsmor]

Don't worry, there is no deadline. ;)