fix(cli): replace ambiguous width characters with halfwidth alternatives#26041
fix(cli): replace ambiguous width characters with halfwidth alternatives#26041Ultron09 wants to merge 1 commit into
Conversation
🛑 Action Required: Evaluation ApprovalSteering changes have been detected in this PR. To prevent regressions, a maintainer must approve the evaluation run before this PR can be merged. Maintainers:
Once approved, the evaluation results will be posted here automatically. |
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 visual alignment and rendering issues in the CLI interface caused by ambiguous-width Unicode characters. By substituting these characters with halfwidth alternatives, the project ensures a more stable and predictable display across different terminal environments, preventing common glitches like character overlapping or truncation. 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 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 counter productive. 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request replaces standard Unicode arrows and indicators with halfwidth variants across the CLI UI and core packages to improve terminal rendering consistency. Feedback was provided to revert these changes in strings specifically sent to the LLM, such as action paths and loop detection prompts, as using non-standard characters in prompts can negatively impact model reasoning and performance.
| .map((p) => p.functionCall!.name) || [], | ||
| ) | ||
| .join(' → '); | ||
| .join(' ￫ '); |
There was a problem hiding this comment.
The use of the halfwidth arrow ￫ (U+FFEB) instead of the standard arrow → (U+2192) in strings sent to the LLM (like the Action Path summary) is discouraged. While this change helps with terminal rendering consistency in the CLI, it can negatively impact the model's performance or reasoning, as → is a much more common token in training data and is semantically standard for indicating transitions. Prompts and system notes sent to the model should prioritize standard Unicode characters over terminal-specific rendering fixes.
| .join(' ￫ '); | |
| .join(' → '); |
| .map((p) => p.functionCall!.name) || [], | ||
| ) | ||
| .join(' → '); | ||
| .join(' ￫ '); |
There was a problem hiding this comment.
Standard arrows should be preserved in strings sent to the model. Terminal rendering concerns should not dictate the content of model prompts.
| .join(' ￫ '); | |
| .join(' → '); |
|
|
||
| Specific patterns to look for: | ||
| - **Alternating cycles with no net effect:** The assistant cycles between the same actions (e.g., edit_file → run_build → edit_file → run_build) where each iteration applies the same edit and encounters the same error, making zero progress. Note: alternating between actions is only a loop if the arguments and outcomes are substantively identical each cycle. If the assistant is modifying different code or getting different errors, that is debugging progress, not a loop. | ||
| - **Alternating cycles with no net effect:** The assistant cycles between the same actions (e.g., edit_file ￫ run_build ￫ edit_file ￫ run_build) where each iteration applies the same edit and encounters the same error, making zero progress. Note: alternating between actions is only a loop if the arguments and outcomes are substantively identical each cycle. If the assistant is modifying different code or getting different errors, that is debugging progress, not a loop. |
There was a problem hiding this comment.
This line is part of the LOOP_DETECTION_PROMPT sent to the LLM. Replacing the standard arrow → with the halfwidth variant ￫ in model instructions is unnecessary and potentially detrimental to the model's understanding of the examples provided. Please revert this change for prompt strings.
| - **Alternating cycles with no net effect:** The assistant cycles between the same actions (e.g., edit_file ￫ run_build ￫ edit_file ￫ run_build) where each iteration applies the same edit and encounters the same error, making zero progress. Note: alternating between actions is only a loop if the arguments and outcomes are substantively identical each cycle. If the assistant is modifying different code or getting different errors, that is debugging progress, not a loop. | |
| - **Alternating cycles with no net effect:** The assistant cycles between the same actions (e.g., edit_file → run_build → edit_file → run_build) where each iteration applies the same edit and encounters the same error, making zero progress. Note: alternating between actions is only a loop if the arguments and outcomes are substantively identical each cycle. If the assistant is modifying different code or getting different errors, that is debugging progress, not a loop. |
|
|
||
| expect(prompt).toContain('The Action Path:'); | ||
| expect(prompt).toContain('tool_a → tool_b'); | ||
| expect(prompt).toContain('tool_a ￫ tool_b'); |
There was a problem hiding this comment.
This test expectation should be reverted to use the standard arrow → to match the suggested fix in the implementation, ensuring that prompts sent to the model remain standard.
| expect(prompt).toContain('tool_a ￫ tool_b'); | |
| expect(prompt).toContain('tool_a → tool_b'); |
gemini-cli
Bot
added
priority/p1
|
Thank you for your interest in contributing to the project! We are closing this PR as it currently does not meet the repository's contribution guidelines. |
3 participants
This PR replaces several Unicode symbols (●, ▲, ■) used in the CLI UI with their halfwidth equivalents.
Some terminal emulators and fonts treat these characters as having ambiguous width, which can cause alignment issues and visual glitches (e.g., characters overlapping or being cut off) in the terminal display. Using halfwidth alternatives ensures consistent rendering across different terminal environments.
This change affects 126 files across the project where these symbols were used as indicators or UI elements.
Fixes #15585