Groundwork for Ttyper moving forward

[philocalyst]

• Building off of Tui-Realm
  • This gives us the interface needed to begin building out integration tests, as it abstracts the actual key-handling logic between message passing
  • Gives a much more structured interface for creating future screens, typing indicators, general UI improvements, the like
  • Allows for the possibility of greater modularity in the future.
• Structured error handling, using Eyre and thiserror.
  • Gives all internal errors types, which should open up routes for recovery logic
  • Eyre allows us to print errors with much more... pizzaz
• General restructuring
  • To make the crate much easier to hack on, and the path towards addition more obvious.

[max-niederman]

I think this work is mostly good, but I strongly dislike the use of a crate::types module for all types. Almost all of the types here are really only used in one or two modules, and have a module that they're naturally scoped to. For example, Opt and Command should be scoped to main.rs, and types::test::{self, handler} should pretty clearly be a top-level test module.

[philocalyst]

Should be good now :) @max-niederman

[philocalyst]

Thank you so much! Will incorporate your comments. Regarding Tokio, is Realm also Smol-compatible? It's not the worst thing in the world, but it would be nice to avoid pulling in something as large as Tokio for a typing test. ▰▰▰▰▰ Miles Wirth 🙃

…

From: hasezoey ***@***.***> Sent: 27 March 2026 01:50 To: max-niederman/ttyper ***@***.***> Cc: Miles Wirht ***@***.***>, Author ***@***.***> Subject: Re: [max-niederman/ttyper] Groundwork for Ttyper moving forward (PR #175) @hasezoey commented on this pull request. > + EventListenerCfg::<NoUserEvent>::default() + .crossterm_input_listener(Duration::from_millis(20), 1) + .poll_timeout(Duration::from_millis(10)) Just as a FYI from a tuirealm developer. This project looks like it cares quite a bit about the speed at which it receives the events and tuirealm's sync event worker is a little slow, as it *always* waits the set duration (in this case `20ms`) between fetching events. I would recommend to use the async worker which can fetch / emit events as soon as they are ready, downside being that it requires a tokio runtime active. > - match state { - State::Test(ref mut test) => { - if let Event::Key(key) = event { - test.handle_key(key); - if test.complete { - state = State::Results(Results::from(&*test)); - } - } +fn event_loop(mut model: Model) -> eyre::Result<()> { + // Terminal initialization (Alternate screen, Raw mode) is already handled by + let _ = model.terminal.clear_screen(); + + while !model.quit { + // Tick + match model.app.tick(PollStrategy::Once) { Another FYI: `PollStrategy::Once` will will *always* wait the set `poll_timeout` (in this case `10ms`), if there is no event and then re-trigger the loop. Looking that there is nothing else running in the loop, consider switching to [`PollStrategy::BlockCollectUpTo`](https://docs.rs/tuirealm/latest/tuirealm/enum.PollStrategy.html#variant.BlockCollectUpTo) This shouldnt be a issue for responsiveness, but are wasted compute cycles. -- Reply to this email directly or view it on GitHub: #175?email_source=notifications&email_token=A3MQBNGXS42A7M475PHPPD34SY6ERA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMBRHE3DQMBUGQZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2L24DSL5ZGK5TJMV3V63TPORUWM2LDMF2GS33OONPWG3DJMNVQ#pullrequestreview-4019680443 You are receiving this because you authored the thread. Message ID: ***@***.***>

[hasezoey]

Smol-compatible

I have not seen that crate yet, without looking it up, i guess it is another async runtime.
(after looking it up, it is practically a continuation of async-std)

Well, currently tuirealm's async mode is only tokio compatible as we require a reference to the runtime handle (which currently is specific to each runtime) to spawn the tasks and use tokio's channels, because tokio is already available(turns out we dont use async channels, i forgot), and frankly tokio is the most commonly used one. (and it is the only one i am currently familiar with)
I guess if there is enough demand, we could implement something to be generic over those handles and switch the other async types.

EDIT: created a issue for it veeso/tui-realm#201

[philocalyst]

Count this as a token of demand then ! ▰▰▰▰▰ Miles Wirth 🙃

…

From: hasezoey ***@***.***> Sent: 27 March 2026 07:05 To: max-niederman/ttyper ***@***.***> Cc: Miles Wirht ***@***.***>, Author ***@***.***> Subject: Re: [max-niederman/ttyper] Groundwork for Ttyper moving forward (PR #175) hasezoey left a comment (max-niederman/ttyper#175) > Smol-compatible I have not seen that crate yet, without looking it up, i guess it is another async runtime. (after looking it up, it is practically a continuation of `async-std`) Well, currently tuirealm's async mode is only tokio compatible as we require a reference to the runtime handle (which currently is specific to each runtime) to spawn the tasks and use tokio's channels, because tokio is already available, and frankly tokio is the most commonly used one. (and it is the only one i am currently familiar with) I guess if there is enough demand, we could implement something to be generic over those handles and switch the other async types. -- Reply to this email directly or view it on GitHub: #175?email_source=notifications&email_token=A3MQBNCXYFHJMNPDSY24IFT4S2DCPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUGI4DKOBXHA32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4142858787 You are receiving this because you authored the thread. Message ID: ***@***.***>

[philocalyst]

Better now, @max-niederman