EdJoPaTo

I still think that the cleanest way to do something like this is wrapping in a custom Backend and not expose the inner workings of Terminal as it could create...

> You mean like #1006 that was closed because this PR was about to get merged? To me #1006 sounds about debugging stuff why it’s the way it is. So...

> not something that would require re-initialization. Put another way, forcing the app to have to fully drop the Terminal in order to temporarily run something in the shell seems...

I used one random example in this repo and adapted it. In my case it was the user_input example because there is input to write to the writer (see the...

The slice type is independent from this project and a Rust type commonly used. Its basically `slice[start..end]` (`

> I apologize for panics caused by my PR To add on @joshka: Multiple reviewers of #987 did not notice this either. It's definitely not an easy to spot issue....

Im not sure that we actually need `RenderRef` and `RenderOwned`. We just need one and implement it either for the `&ListWidget` or for `ListWidget` (`impl Render for &ListWidget`). That way...

Why not use a single trait and decide about ref or whatever on the implementation? `impl Whatever for &mut List`

Given the confusions about the render traits… Should it be a trait in the first place? A struct feels long-term, so people expect them to be long-term. Splitting this up...

> This is effectively isomorphic (or functionally equivalent) to what we already have. Thats the point. > A struct feels long-term, so people expect them to be long-term. > Splitting...