use setcbreak instead of setraw, fixes #53

[insidewhy]

Tested locally, works much better. setcbreak is definitely a better option than setraw.

See https://www.tutorialspoint.com/terminal-control-functions-in-python for more info.

[C0D3D3V]

This breaks already functioning systems like cutie.
Because the cursor behaviour is quite different.

[insidewhy]

@C0D3D3V You could build cutie with just readchar? I thought it was using something like curses. Interesting. I would have thought the majority of use cases for readchar wouldn't want to alter the way the enter key works, is it not something you can work around, or maybe there was already a work around in your code that this breaks and you can remove?

[C0D3D3V]

Yes, I was a bit hasty, sorry. Cutie still works. Only the keycode of the enter key is wrong as I pointed out in my PR.

[magmax]

Wow... Cutie is very similar to inquirer, the reason that made me write readchar XD

Do you think we should revert this?

[insidewhy]

I think the majority of people don't want the enter key to do weird unexpected stuff and it should be easier to work around this being on than this being off

[magmax]

Reverted as v3.0.4

[C0D3D3V]

I just tested inquirer with the setcbreak mode, there the same happens as with cutie, the enter key is not recognized because in the mode another keycode is generated (\x0a instead of \x0d). That is actually all, if you adjust the keycode, then it should work as before. But I have not tested everything... that should perhaps be made before such a change (also across all platforms) so that the created tools do not break.

We could also define the enter code to be both "\x0d" and "\x0a", then the problem would not exist.

[insidewhy]

Reverted as v3.0.4

Noooo

[magmax]

I cannot break previous way of work.
I will add a way to choose if you want one or another later.
Right now, @insidewhy , you can fix your program to the version 3.0.3