This is a minor issue noted during the review of #10.
render_progress and the scroll_offset advancement logic in wait_with_progress each call size() independently. If the terminal is resized in the window between the two calls, the marquee scroll can stutter by one tick — advancing when the header was not actually drawn as a marquee, or not advancing when it was.
In practice this is nearly undetectable: the stutter requires a resize to land in a ~500ms window and only skips or repeats a single character of scroll. Normal playback is unaffected.
The fix would be to have render_progress return the term_width snapshot it used alongside the existing bool, and have the caller use that value for the marquee check instead of calling size() again. This would change the return type from bool to (bool, u16) and require updating all three call sites.
This is a minor issue noted during the review of #10.
render_progressand thescroll_offsetadvancement logic inwait_with_progresseach callsize()independently. If the terminal is resized in the window between the two calls, the marquee scroll can stutter by one tick — advancing when the header was not actually drawn as a marquee, or not advancing when it was.In practice this is nearly undetectable: the stutter requires a resize to land in a ~500ms window and only skips or repeats a single character of scroll. Normal playback is unaffected.
The fix would be to have
render_progressreturn theterm_widthsnapshot it used alongside the existingbool, and have the caller use that value for the marquee check instead of callingsize()again. This would change the return type fromboolto(bool, u16)and require updating all three call sites.