Summary
On Windows, the default regular/main-screen TUI can leave previous slash-command autocomplete rows on screen while typing. In openpi this looks like login/logout (and the /, /l, /lo intermediate states) are registered multiple times, but the command registry is not duplicated; the stale rows are terminal redraw artifacts.
Reproduction
Environment observed:
- Windows terminal (PowerShell/Windows Terminal)
- Pi 0.85.0
@tt-a1i/openpi 0.5.0- openpi extensions loaded from a single package entry
Steps:
- Start openpi in the default
regular TUI mode.
- Type
/ and then /lo without submitting.
- Observe that previous autocomplete rows remain visible and overlap the current list.
Expected: only the current autocomplete list is visible.
Actual: earlier rendered rows remain visible, making commands appear duplicated. The command still resolves correctly.
Root cause
The regular TUI uses differential rendering against the main terminal screen. On Windows, the redraw/cursor bookkeeping can fail for the multi-line autocomplete editor, leaving stale rows in the terminal scrollback. The same class of symptom is tracked upstream in earendil-works/pi#6300.
Proposed fix
Add an openpi Windows terminal compatibility layer that prevents this class of stale redraws, while preserving an explicitly configured user choice. The safest fallback is fullscreen/alternate-screen mode; a regular-mode forced redraw fallback may also be considered if the extension API supports it without replacing user UI components.
The fix should include:
- Windows-only behavior;
- no change when the user explicitly chooses a TUI mode;
- a regression test for the compatibility decision;
- setup documentation explaining how to override the behavior.
This issue is intended to track the openpi-side mitigation and the follow-up pull request.
Summary
On Windows, the default regular/main-screen TUI can leave previous slash-command autocomplete rows on screen while typing. In openpi this looks like
login/logout(and the/,/l,/lointermediate states) are registered multiple times, but the command registry is not duplicated; the stale rows are terminal redraw artifacts.Reproduction
Environment observed:
@tt-a1i/openpi0.5.0Steps:
regularTUI mode./and then/lowithout submitting.Expected: only the current autocomplete list is visible.
Actual: earlier rendered rows remain visible, making commands appear duplicated. The command still resolves correctly.
Root cause
The regular TUI uses differential rendering against the main terminal screen. On Windows, the redraw/cursor bookkeeping can fail for the multi-line autocomplete editor, leaving stale rows in the terminal scrollback. The same class of symptom is tracked upstream in earendil-works/pi#6300.
Proposed fix
Add an openpi Windows terminal compatibility layer that prevents this class of stale redraws, while preserving an explicitly configured user choice. The safest fallback is fullscreen/alternate-screen mode; a regular-mode forced redraw fallback may also be considered if the extension API supports it without replacing user UI components.
The fix should include:
This issue is intended to track the openpi-side mitigation and the follow-up pull request.