feat(terminal): add Terminal::try_draw() method

[joshka]

This makes it easier to write fallible rendering methods that can use the ? operator

terminal.try_draw(|frame| {
    some_method_that_can_fail()?;
    another_faillible_method()?;
    Ok(())
})?;

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.4%. Comparing base (3f2f2cd) to head (5f4e508).
Report is 10 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff           @@
##            main   #1209    +/-   ##
======================================
  Coverage   94.4%   94.4%            
======================================
  Files         62      62            
  Lines      14941   15056   +115     
======================================
+ Hits       14110   14225   +115     
  Misses       831     831            

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kdheepak]

Cool idea! LGTM! Curious what other people think.

[joshka]

Cool idea! LGTM! Curious what other people think.

@EdJoPaTo ?

[EdJoPaTo]

This simplifies the rendering but I'm not sure how useful it actually might be. Ideally the same Render Widget or whatever its named trait should exist here too I think? That would reduce the differences. Especially as a context is of interest anyway and Frame would reduce the need for the context too.
And the current trait doesn't allow for a Result currently either? Not sure what the ideal way would be.

[EdJoPaTo]

Either empty lines between both or no empty lines. It took me a moment to realise where render is defined as the comment looked like its somewhere completely else.

[joshka]

Are you looking at the rendered docs?

[joshka]

This simplifies the rendering but I'm not sure how useful it actually might be. Ideally the same Render Widget or whatever its named trait should exist here too I think? That would reduce the differences. Especially as a context is of interest anyway and Frame would reduce the need for the context too.
And the current trait doesn't allow for a Result currently either? Not sure what the ideal way would be.

I regularly find myself using methods which return results and having to throw away the possible errors inside of the draw method by either crashing or ignoring them. This would make it possible to add more context to the errors (using anyhow / eyre), and have the app more gracefully crash.

This is a first point in making some of these future things more useful. We don't need to solve the entire problem, but this is a piece that is fine and necessary on its own.