Feature: developing a context handler

[Cube707]

Due to the way readchar currently handles terminal setup, we cannot control terminal behaviour outside of the two readchar functions. This leads to issues #62 and #73

We could solve this by externalising terminal setup and teardown and have it run at the beginning and end, ensuring consistent behaviour in between. Under python this calls for a Context Manager

Requirements would be:

• setting up the terminal for readchars needs, this means:
  • no echoing or other handeling of typed keys. They need to be waiting untill readchar calls read the next time
  • no interruptions, readchar will read CTRL+C etc. As normal keystrokesand handle them
  • whatever else is needet to ensure readchar works consistently
• giving a way to check if a key is waiting to be read
• reading chars and keys as with the current behavior
• ensuring consistent behaviour above both platform's (even if that means limiting one)
• decide on good, intuitive names
• document the new feature

Here is an example of how it could work:

With ReadChar() as read:
    if read.key_iswaiting():
        print(read.key())

    #other stuff in parallel #
    sleep(0.5)

If this is working an properly set up, I could replace the existing functions and they could be simply wrappers for this.

[Cube707]

@petereon i opened a new issue to discuss this. Feel free to drop more questions

For more context read:
#62 (comment)
And everything in #73

[petereon]

Perfect, thank you very much for an exhaustive description. I wonder if it doesn't sound like a good opportunity to utilize Queues and reactive paradigm.

That would give us a very good way to check if there is a character waiting for processing with a FIFO Queue's get method. With asyncio, it should also deal with the back pressure, if someone typed faster than it is able to process mentioned in #73 . For some reference, consider this article and specifically this code snippet. Does that sound like something that could fit into the current architecture?

[Cube707]

While this would defnetly be a reasonable approach where we to rewrite all of he input gathering yourselfs.

But lukily the operating system already handles most of the heavy lifting. We just need to configure it to match our needs. So don't overcomplicate it.

[petereon]

Yeah, that sounds like a pretty sane approach. I am just unsure how to handle the none-blocking read then. Sounds like there is either going to have to be an async event-loop or separate process/thread in that case.

[Cube707]

No, the terminal is already a queue and you can query it for content. On windows its super simple as there is a function for it. msvcrt.kbhit() returns true if there are keypresses waiting to be read.

On linux use this https://gist.github.com/michelbl/efda48b19d3e587685e3441a74457024#file-kbhit-py-L103-L111

[Cube707]

Also check out this development version that I made but didn't use

https://github.com/Cube707/python-readchar/blob/c3081ec51581ead9b4db2f60a8f1567ed809d06a/readchar/posix_read.py

https://github.com/Cube707/python-readchar/blob/c3081ec51581ead9b4db2f60a8f1567ed809d06a/readchar/win_read.py

[petereon]

Great, thank you for the information and apologies for how very uninformed I am about tty. I'll take a deep dive in this stuff in coming days 😃

[Cube707]

No worry. The reason I never used the development version is that I didn't know enough and thought it would work just like that. Turned out its more complicated 😂

[Cube707]

Also keep in mind that on the windows side a lot of stuff doesn't work, so this will mostlikley be the limiting factor. So don't spend to much time (unless you want to 😆)

[petereon]

I will have a proper read into this. Good opportunity to learn how OS's handle this stuff 😄. It might take a bit of time.

[Cube707]

take your time. there is no rush.

I will also have more time in the coming weeks, as my thesis is due tomorrow and will no longer eat up my schedule

[petereon]

Good luck with your thesis, mate. So glad I am done with that stuff already 😃

…

On Sun, Sep 11, 2022, 13:53 Jan Wille ***@***.***> wrote: take your time. there is no rush. I will also have more time in the coming weeks, as my thesis is due tomorrow and no longer eat up my schedule — Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALGZGPORQAA37NXTURFU3MLV5XB4LANCNFSM6AAAAAAQJMRZIA> . You are receiving this because you were assigned.Message ID: ***@***.***>