Regenerated against alef 0.25.50: swift backend struct-field #[cfg] filtering (fixes UndeclaredType parse panic), inbound-bridge recursion, and manual-Default data-enum gating. See CHANGELOG.md [5.0.0-rc.25].

• fix(node): restore optionalDependencies so platform binaries install by @AstraBert in https://github.com/run-llama/liteparse/pull/312

Full Changelog: https://github.com/run-llama/liteparse/compare/crates-v2.1.1...node-v2.1.2

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina crate
  • expose the backend through the termina feature and Ratatui prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI, xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal cell, the trailing cell does not get an update if its content does not change. But if the wide cell has a background (or other) style, the terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large relative to the track. With the position at the end, part_lengths clamped thumb_start to track_length - 1 while thumb_length was clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end and zips it against the cells of the area. When the thumb overruns the track, track_end saturates to 0 but the thumb still emits more cells than the track can hold, so the trailing end symbol is pushed past the end of the area. The last visible cell ends up being a thumb (█) where the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17, thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of track_length - 1) so the thumb always fits within the track and the end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks part_lengths directly with the issue's parameters — asserts thumb_start + thumb_length <= track_length and that the parts sum to the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582 case (both arrows, large thumb at the end) and asserts the end symbol is drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete is a fast static source scan, which is why it missed the package-level unused deps fixed in #2598 when the same dependency names were still referenced by example crates. cargo-udeps compiles the workspace and checks rustc dep-info, so it can catch unused dependency declarations for the package being checked.

  To make the new job pass, this also removes the remaining true-positive unused dev-deps and records explicit cargo-udeps ignores for current false positives / intentional cases: ratatui-core critical-section, ratatui-crossterm's duplicate crossterm version feature shape, and ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo udeps". I did not find prior ratatui discussion about adopting cargo-udeps; the only hits were Dependabot PR bodies for taiki-e/install-action release notes mentioning cargo-udeps version updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] → [dev-dependencies]:

  • indoc

  ---

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

  Precedent

  I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click it.
  • It does not skip review requirements, status checks, labels, or any other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
  • Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

  GitHub docs

  • Automatically merging a pull request
  • Managing auto-merge for pull requests in your repository
  • About rulesets
  • Require status checks to pass before merging
  • About status checks
  • Troubleshooting required status checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status context required
  • Verified this PR has squash auto-merge enabled and is blocked pending checks/review

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: https://github.com/ratatui/ratatui/compare/ratatui-v0.30.1...ratatui-v0.30.2

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina crate
  • expose the backend through the termina feature and Ratatui prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI, xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal cell, the trailing cell does not get an update if its content does not change. But if the wide cell has a background (or other) style, the terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large relative to the track. With the position at the end, part_lengths clamped thumb_start to track_length - 1 while thumb_length was clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end and zips it against the cells of the area. When the thumb overruns the track, track_end saturates to 0 but the thumb still emits more cells than the track can hold, so the trailing end symbol is pushed past the end of the area. The last visible cell ends up being a thumb (█) where the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17, thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of track_length - 1) so the thumb always fits within the track and the end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks part_lengths directly with the issue's parameters — asserts thumb_start + thumb_length <= track_length and that the parts sum to the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582 case (both arrows, large thumb at the end) and asserts the end symbol is drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete is a fast static source scan, which is why it missed the package-level unused deps fixed in #2598 when the same dependency names were still referenced by example crates. cargo-udeps compiles the workspace and checks rustc dep-info, so it can catch unused dependency declarations for the package being checked.

  To make the new job pass, this also removes the remaining true-positive unused dev-deps and records explicit cargo-udeps ignores for current false positives / intentional cases: ratatui-core critical-section, ratatui-crossterm's duplicate crossterm version feature shape, and ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo udeps". I did not find prior ratatui discussion about adopting cargo-udeps; the only hits were Dependabot PR bodies for taiki-e/install-action release notes mentioning cargo-udeps version updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] → [dev-dependencies]:

  • indoc

  ---

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

  Precedent

  I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click it.
  • It does not skip review requirements, status checks, labels, or any other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
  • Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

  GitHub docs

  • Automatically merging a pull request
  • Managing auto-merge for pull requests in your repository
  • About rulesets
  • Require status checks to pass before merging
  • About status checks
  • Troubleshooting required status checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status context required
  • Verified this PR has squash auto-merge enabled and is blocked pending checks/review

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: https://github.com/ratatui/ratatui/compare/ratatui-v0.30.1...ratatui-v0.30.2

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina crate
  • expose the backend through the termina feature and Ratatui prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI, xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal cell, the trailing cell does not get an update if its content does not change. But if the wide cell has a background (or other) style, the terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large relative to the track. With the position at the end, part_lengths clamped thumb_start to track_length - 1 while thumb_length was clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end and zips it against the cells of the area. When the thumb overruns the track, track_end saturates to 0 but the thumb still emits more cells than the track can hold, so the trailing end symbol is pushed past the end of the area. The last visible cell ends up being a thumb (█) where the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17, thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of track_length - 1) so the thumb always fits within the track and the end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks part_lengths directly with the issue's parameters — asserts thumb_start + thumb_length <= track_length and that the parts sum to the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582 case (both arrows, large thumb at the end) and asserts the end symbol is drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete is a fast static source scan, which is why it missed the package-level unused deps fixed in #2598 when the same dependency names were still referenced by example crates. cargo-udeps compiles the workspace and checks rustc dep-info, so it can catch unused dependency declarations for the package being checked.

  To make the new job pass, this also removes the remaining true-positive unused dev-deps and records explicit cargo-udeps ignores for current false positives / intentional cases: ratatui-core critical-section, ratatui-crossterm's duplicate crossterm version feature shape, and ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo udeps". I did not find prior ratatui discussion about adopting cargo-udeps; the only hits were Dependabot PR bodies for taiki-e/install-action release notes mentioning cargo-udeps version updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] → [dev-dependencies]:

  • indoc

  ---

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

  Precedent

  I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click it.
  • It does not skip review requirements, status checks, labels, or any other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
  • Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

  GitHub docs

  • Automatically merging a pull request
  • Managing auto-merge for pull requests in your repository
  • About rulesets
  • Require status checks to pass before merging
  • About status checks
  • Troubleshooting required status checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status context required
  • Verified this PR has squash auto-merge enabled and is blocked pending checks/review

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: https://github.com/ratatui/ratatui/compare/ratatui-v0.30.1...ratatui-v0.30.2

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina crate
  • expose the backend through the termina feature and Ratatui prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI, xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal cell, the trailing cell does not get an update if its content does not change. But if the wide cell has a background (or other) style, the terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large relative to the track. With the position at the end, part_lengths clamped thumb_start to track_length - 1 while thumb_length was clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end and zips it against the cells of the area. When the thumb overruns the track, track_end saturates to 0 but the thumb still emits more cells than the track can hold, so the trailing end symbol is pushed past the end of the area. The last visible cell ends up being a thumb (█) where the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17, thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of track_length - 1) so the thumb always fits within the track and the end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks part_lengths directly with the issue's parameters — asserts thumb_start + thumb_length <= track_length and that the parts sum to the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582 case (both arrows, large thumb at the end) and asserts the end symbol is drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete is a fast static source scan, which is why it missed the package-level unused deps fixed in #2598 when the same dependency names were still referenced by example crates. cargo-udeps compiles the workspace and checks rustc dep-info, so it can catch unused dependency declarations for the package being checked.

  To make the new job pass, this also removes the remaining true-positive unused dev-deps and records explicit cargo-udeps ignores for current false positives / intentional cases: ratatui-core critical-section, ratatui-crossterm's duplicate crossterm version feature shape, and ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo udeps". I did not find prior ratatui discussion about adopting cargo-udeps; the only hits were Dependabot PR bodies for taiki-e/install-action release notes mentioning cargo-udeps version updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] → [dev-dependencies]:

  • indoc

  ---

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

  Precedent

  I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click it.
  • It does not skip review requirements, status checks, labels, or any other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
  • Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

  GitHub docs

  • Automatically merging a pull request
  • Managing auto-merge for pull requests in your repository
  • About rulesets
  • Require status checks to pass before merging
  • About status checks
  • Troubleshooting required status checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status context required
  • Verified this PR has squash auto-merge enabled and is blocked pending checks/review

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: https://github.com/ratatui/ratatui/compare/ratatui-v0.30.1...ratatui-v0.30.2

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina crate
  • expose the backend through the termina feature and Ratatui prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI, xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal cell, the trailing cell does not get an update if its content does not change. But if the wide cell has a background (or other) style, the terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large relative to the track. With the position at the end, part_lengths clamped thumb_start to track_length - 1 while thumb_length was clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end and zips it against the cells of the area. When the thumb overruns the track, track_end saturates to 0 but the thumb still emits more cells than the track can hold, so the trailing end symbol is pushed past the end of the area. The last visible cell ends up being a thumb (█) where the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17, thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of track_length - 1) so the thumb always fits within the track and the end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks part_lengths directly with the issue's parameters — asserts thumb_start + thumb_length <= track_length and that the parts sum to the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582 case (both arrows, large thumb at the end) and asserts the end symbol is drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete is a fast static source scan, which is why it missed the package-level unused deps fixed in #2598 when the same dependency names were still referenced by example crates. cargo-udeps compiles the workspace and checks rustc dep-info, so it can catch unused dependency declarations for the package being checked.

  To make the new job pass, this also removes the remaining true-positive unused dev-deps and records explicit cargo-udeps ignores for current false positives / intentional cases: ratatui-core critical-section, ratatui-crossterm's duplicate crossterm version feature shape, and ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo udeps". I did not find prior ratatui discussion about adopting cargo-udeps; the only hits were Dependabot PR bodies for taiki-e/install-action release notes mentioning cargo-udeps version updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] → [dev-dependencies]:

  • indoc

  ---

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

  Precedent

  I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click it.
  • It does not skip review requirements, status checks, labels, or any other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
  • Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

  GitHub docs

  • Automatically merging a pull request
  • Managing auto-merge for pull requests in your repository
  • About rulesets
  • Require status checks to pass before merging
  • About status checks
  • Troubleshooting required status checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status context required
  • Verified this PR has squash auto-merge enabled and is blocked pending checks/review

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: https://github.com/ratatui/ratatui/compare/ratatui-v0.30.1...ratatui-v0.30.2

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina crate
  • expose the backend through the termina feature and Ratatui prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI, xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal cell, the trailing cell does not get an update if its content does not change. But if the wide cell has a background (or other) style, the terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large relative to the track. With the position at the end, part_lengths clamped thumb_start to track_length - 1 while thumb_length was clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end and zips it against the cells of the area. When the thumb overruns the track, track_end saturates to 0 but the thumb still emits more cells than the track can hold, so the trailing end symbol is pushed past the end of the area. The last visible cell ends up being a thumb (█) where the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17, thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of track_length - 1) so the thumb always fits within the track and the end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks part_lengths directly with the issue's parameters — asserts thumb_start + thumb_length <= track_length and that the parts sum to the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582 case (both arrows, large thumb at the end) and asserts the end symbol is drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete is a fast static source scan, which is why it missed the package-level unused deps fixed in #2598 when the same dependency names were still referenced by example crates. cargo-udeps compiles the workspace and checks rustc dep-info, so it can catch unused dependency declarations for the package being checked.

  To make the new job pass, this also removes the remaining true-positive unused dev-deps and records explicit cargo-udeps ignores for current false positives / intentional cases: ratatui-core critical-section, ratatui-crossterm's duplicate crossterm version feature shape, and ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo udeps". I did not find prior ratatui discussion about adopting cargo-udeps; the only hits were Dependabot PR bodies for taiki-e/install-action release notes mentioning cargo-udeps version updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] → [dev-dependencies]:

  • indoc

  ---

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

  Precedent

  I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click it.
  • It does not skip review requirements, status checks, labels, or any other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
  • Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

  GitHub docs

  • Automatically merging a pull request
  • Managing auto-merge for pull requests in your repository
  • About rulesets
  • Require status checks to pass before merging
  • About status checks
  • Troubleshooting required status checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status context required
  • Verified this PR has squash auto-merge enabled and is blocked pending checks/review

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: https://github.com/ratatui/ratatui/compare/ratatui-v0.30.1...ratatui-v0.30.2

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina crate
  • expose the backend through the termina feature and Ratatui prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI, xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal cell, the trailing cell does not get an update if its content does not change. But if the wide cell has a background (or other) style, the terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large relative to the track. With the position at the end, part_lengths clamped thumb_start to track_length - 1 while thumb_length was clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end and zips it against the cells of the area. When the thumb overruns the track, track_end saturates to 0 but the thumb still emits more cells than the track can hold, so the trailing end symbol is pushed past the end of the area. The last visible cell ends up being a thumb (█) where the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17, thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of track_length - 1) so the thumb always fits within the track and the end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks part_lengths directly with the issue's parameters — asserts thumb_start + thumb_length <= track_length and that the parts sum to the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582 case (both arrows, large thumb at the end) and asserts the end symbol is drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete is a fast static source scan, which is why it missed the package-level unused deps fixed in #2598 when the same dependency names were still referenced by example crates. cargo-udeps compiles the workspace and checks rustc dep-info, so it can catch unused dependency declarations for the package being checked.

  To make the new job pass, this also removes the remaining true-positive unused dev-deps and records explicit cargo-udeps ignores for current false positives / intentional cases: ratatui-core critical-section, ratatui-crossterm's duplicate crossterm version feature shape, and ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo udeps". I did not find prior ratatui discussion about adopting cargo-udeps; the only hits were Dependabot PR bodies for taiki-e/install-action release notes mentioning cargo-udeps version updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] → [dev-dependencies]:

  • indoc

  ---

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

  Precedent

  I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click it.
  • It does not skip review requirements, status checks, labels, or any other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
  • Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

  GitHub docs

  • Automatically merging a pull request
  • Managing auto-merge for pull requests in your repository
  • About rulesets
  • Require status checks to pass before merging
  • About status checks
  • Troubleshooting required status checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status context required
  • Verified this PR has squash auto-merge enabled and is blocked pending checks/review

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: https://github.com/ratatui/ratatui/compare/ratatui-v0.30.1...ratatui-v0.30.2

• deps: upgrade dependencies to latest — liter-llm 1.7.1, html-to-markdown-rs 3.6.15, tree-sitter-language-pack 1.9.1, bitvec 1.1, plus refreshed Cargo.lock, pnpm-lock.yaml, and uv.lock.

• presets: derive Clone on Registry. The Dart FRB mirror crate generates a borrowed-return accessor for the Registry::global() singleton that clones the borrowed value before the owned From conversion (Mirror::from(v.clone())); without Clone on Registry this failed to compile (From<&kreuzberg::Registry> not satisfied). Preset already derived Clone.
• android: add classification, captioning, and ner-llm to the android-target aggregate feature. These are LLM-driven (liter-llm/HTTP) and do not depend on ONNX Runtime, so they are safe on the no-ORT Android emulator surface. The Dart FRB dispatch (frb_generated.rs) is not feature-aware and referenced classify_document, caption_image, and LlmBackend unconditionally, so the binding crate failed to compile under android-target without them (E0425).
• alef: bump alef_version to 0.25.47 and regenerate all bindings. Picks up the Dart rust-crate codegen fixes — converted slice arguments now borrow correctly, and opaque use/impl blocks are cfg-gated to match their source items.