Repository navigation
fix(cli): cap pending plain text height to reduce streaming flicker - #29629
shamanshetty07 wants to merge 2 commits into
Conversation
While a response streams in the default (non-alternate-buffer) mode, plain text such as long lists or paragraphs was not height-limited; only code blocks were. The frame could grow taller than the terminal, which makes Ink clear the screen and rewrite the full history on every update. Wrap pending markdown in MaxSizedBox so only the most recent lines that fit in availableTerminalHeight are shown. Completed messages and alternate-buffer mode are unchanged.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
📊 PR Size: size/M
|
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a visual flickering issue in the CLI during streaming responses. By capping the height of pending markdown content when not in alternate buffer mode, the application avoids triggering Ink's full-screen clear-and-redraw logic, significantly improving the stability of the terminal display during long streaming outputs. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces height capping for pending markdown plain text when not in alternate buffer mode. By wrapping the content blocks in a MaxSizedBox component constrained to the available terminal height, it prevents Ink from clearing and redrawing the entire screen during streaming updates. Corresponding unit tests have been added to verify this behavior for both pending and completed text. I have no additional feedback to provide as the implementation is clean and well-tested.
|
@googlebot I signed it! |
Summary
Cap the height of pending (streaming) plain text in
MarkdownDisplayso the frame stays shorter than the terminal in the default rendering mode. This removes the full-screen clear-and-redraw that happens on every streamed update when a response grows taller than the terminal.Details
availableTerminalHeightwas applied only to code blocks. Paragraphs and list items were not limited, so a long streamed list could make the frame taller than the terminal.renderFullTerminal(clearTerminal+ full static history + frame) instead of the incremental path. During streaming that repeats on every token update.MaxSizedBox(overflowDirection="top"), so the latest lines stay visible with a "lines hidden" note. Completed messages and alternate-buffer mode are unchanged.useFlickerDetectoris intentionally left as is. In alternate-buffer mode the root box height is fixed at the terminal height, so changing its>check to>=would report on every render.Measured with the CLI run from source in a pseudo-terminal (macOS), prompt "Write a long numbered list of 60 programming tips, one line each", counting frames where Ink took the full-clear path (temporary logging in Ink, not included in this PR):
One additional "before" run at 60 rows never produced the list, so it is excluded. Render counts depend on model speed and are not directly comparable; the full-clear frame count is the relevant number. Total bytes written were not meaningfully reduced (spinner redraws remain), so the benefit is no full-screen clears, not less output.
Related Issues
Related to #29628
How to Validate
npm run build, then run the CLI with default settings in a short terminal (for example 20 or 60 rows).npm test -w @google/gemini-cli -- src/ui/utils/MarkdownDisplay.test.tsxnpm run preflight: lint, typecheck and all other tests pass. One test inpackages/core(ShellExecutionService > Orphan PTY slave FD cleanup ... darwin) fails on a cleanupstream/mainas well and is unrelated to this change.Pre-Merge Checklist