fix(cli): align table rows containing inline markdown#20359
fix(cli): align table rows containing inline markdown#20359dlezama wants to merge 3 commits intogoogle-gemini:mainfrom
Conversation
TableRenderer measured cell width including markdown markers (backticks, bold **, strikethrough ~~, etc.) but RenderInline strips those markers when rendering. This caused rows with inline code like `/help` to be visually narrower than rows with plain text. Extract parseInlineMarkdown() as a shared parser that both RenderInline (React nodes) and the new stripInlineMarkdown() (plain text projection) consume. TableRenderer now uses stripInlineMarkdown to compute the actual rendered width for padding, keeping all rows aligned.
|
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. |
Summary of ChangesHello @dlezama, 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 bug in the CLI's table rendering where rows containing inline markdown would appear misaligned. The solution involves centralizing the logic for parsing inline markdown, allowing for consistent interpretation across both rendering and plain-text width calculation. This ensures that tables are displayed correctly, regardless of the markdown content within their cells, significantly improving the user interface's consistency and readability. Highlights
Changelog
Activity
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. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request effectively resolves the table alignment issue caused by inline markdown. The refactoring of the markdown parsing logic into a centralized parseInlineMarkdown function is a great improvement for maintainability. I've added one comment regarding a potential edge case in the new parser's logic for handling code spans, emphasizing the need for robust input handling.
…rkdown-alignment # Conflicts: # packages/cli/src/ui/utils/TableRenderer.tsx
Replace the regex-based code span matcher (`+.+?`+) with a dedicated scanCodeSpan function that counts the opening backtick run length and scans for a closing run of exactly the same length. This correctly handles cases like ``a`b`` (content: a`b) and ```a``b``` (content: a``b) where the previous regex would match only the first backtick pair and fall back to plain text. The scanner is interleaved with the existing INLINE_REGEX: at each position, backticks are checked first (code spans have highest priority in CommonMark), then the regex handles other inline markers. Add 5 tests covering double- and triple-backtick code spans with embedded backticks for both parseInlineMarkdown and stripInlineMarkdown.
874fd92 to
c1dbc78
Compare
|
Thanks for your PR. However there is already an in-progress fix for this. Feel free to test and help review that PR. |
Summary
Fix table row misalignment when cells contain inline markdown (backticks, bold, strikethrough, etc.). Rows with inline code like
`/help`rendered 2 characters narrower than plain-text rows becauseTableRenderermeasured width including markdown markers thatRenderInlinestrips during rendering.Details
Root cause:
renderCell()inTableRendererusedstyledCharsWidthon raw cell text (e.g.,`/help`= 7 chars) to calculate padding. ButRenderInlinestrips the backticks and renders/help(5 chars). The padding was 2 chars too small per backtick pair, causing visible misalignment in the right border.Fix: Extract
parseInlineMarkdown()as a shared parser returning typedMarkdownSegment[]segments. BothRenderInline(React nodes) and the newstripInlineMarkdown()(plain text projection) consume these segments.TableRenderernow usesstripInlineMarkdownto compute the actual rendered width for padding calculation.This eliminates the previous duplication concern — the parsing logic exists in exactly one place.
Files changed:
InlineMarkdownRenderer.tsx— Refactored: extractedparseInlineMarkdown()shared parser,RenderInlinenow maps segments to React nodes, addedstripInlineMarkdown()for plain-text width measurementTableRenderer.tsx—renderCell()usesstripInlineMarkdownfor accuratedisplayWidthInlineMarkdownRenderer.test.tsx— New: 29 tests covering parser, strip function, and component renderingTableRenderer.test.tsx— Added 2 regression tests for inline markdown alignmentRelated Issues
How to Validate
npm test -w @google/gemini-cli -- src/ui/utils/TableRenderer.test.tsxTableRenderer.tsxchange and run the "backtick-wrapped inline code" test — it will fail with rows at width 49 vs 51.Pre-Merge Checklist