keyboard wrapper

[sethp]

Ok, I wrote you a long letter over at https://github.com/rustbox/esp32c3-vgaterm/discussions/21 , but I think for the purposes of this PR: maybe we focus on flattening the control hierarchy so that the main loop owns all the components and all the data, and is responsible for taking outputs and feeding inputs until the thing burps? At least it'd all be in one place then. As for provenance: this idea is derived mostly from experience with building event loops being more fun when there's just one level of handlers to call and they don't really "nest".

So, here, that'd be something like:

1. move flush_and_parse out from Keyboard and into something that main calls and returns a Vec of events
2. main loops over the events and feeds them into the pressed set, one by one, and calls input.key_char(keyboard.current())
3. possibly: change terminal_input::key_char to (also) return the delay (deadline?), then main can start/reset a timer for that amount of time?

That way, we wouldn't drop any key presses, we can decouple the keypress delay from the frame rate, we have an effective lifetime root if/when we do want to start passing refs around (main can easily own things from one function call to the next), and we squish out all the nasty, sneaky little objecttsess ?

[dougli1sqrd]

This is cool! This makes me wonder again what we think the final api should kinda look like? I guess in the final form I'd like something that's like

let kb = KeyboardInputThing::new(Keyboard::from_peripherals(...));
loop {
    ...
    let chars  = kb.next_chars();
    ...
    unsafe { wfi() }
} 

and that would go in the main loop thing you have in keypad. Should KeyboardInputThing be TerminalInput? I guess I'm thinking the terminal input should own the keyboard?

[sethp]

Ah, looks like we are down to the tacks of brass: I think I'm proposing the opposite. In my mental model, I'm leaning towards anything that's doing significant work (or especially anything that might "block," like receiving from a channel) ought to be no more than one call frame deep from main.

But this is the fun part: we smash our mental models together and see what shakes out! Do you want to try what you're thinking of and then we can compare?

[dougli1sqrd]

Yeah! Maybe we can do that together even, since I want to preserve your preference for "data centricism" and I have aspirations towards data centrism as well.