feat(extensions): support dim tone in line highlighters (#852) - #909
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryAdds the
Confidence Score: 4/5The PR appears safe to merge, with only a non-blocking documentation formatting issue to address. The dim tone is propagated through the public types, CLI and daemon contracts, validation, storage, and production paint path, and no concrete behavioral or security failure remains; the sole accepted concern is an overlong modified documentation line. Files Needing Attention: website/src/content/docs/docs/extend/extension-api.md Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
Extension[Extension highlighter] --> Validation[Highlight validation]
CLI[Session CLI] --> Protocol[Daemon protocol]
Protocol --> Validation
Validation --> Marks[Stored line marks]
Marks --> Paint[Span paint resolution]
Paint --> Dim[Foreground blended toward effective background]
Prompt To Fix All With AI### Issue 1
website/src/content/docs/docs/extend/extension-api.md:147
**Overlong extension API paragraph**
The expanded line-highlight documentation remains on one line far beyond the repository's 120-character limit, making this public API contract harder to review and maintain. Please wrap the paragraph to conform to the required formatting convention.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "feat(extensions): support dim tone in li..." | Re-trigger Greptile |
| ``` | ||
|
|
||
| Marks are addressed by source coordinates — `side`, a 1-based `line`, and a `[start, end)` range in UTF-16 code units of the raw line text — so they survive split vs stack layout, wrapping, horizontal scrolling, and collapsed-context expansion. A mark paints terminal columns, so a range covering only zero-width characters (bidi controls, ZWSP) paints nothing. Tones (`match`, `current`, `info`, `warning`, `error`) rather than colors: Hunk resolves each tinted tone against the actual background of each marked line with a minimum-contrast guarantee stronger than its own word-diff emphasis, so a mark is never invisible on an added line's green; on a transparent cell the tint is resolved against the background Hunk assumes rather than the one behind the terminal. `current` renders as reverse video, the `less`/vim convention for the active hit. | ||
| Marks are addressed by source coordinates — `side`, a 1-based `line`, and a `[start, end)` range in UTF-16 code units of the raw line text — so they survive split vs stack layout, wrapping, horizontal scrolling, and collapsed-context expansion. A mark paints terminal columns, so a range covering only zero-width characters (bidi controls, ZWSP) paints nothing. Tones (`match`, `current`, `info`, `warning`, `error`, `dim`) rather than colors: Hunk resolves each tinted tone against the actual background of each marked line with a minimum-contrast guarantee stronger than its own word-diff emphasis, so a mark is never invisible on an added line's green; `dim` recedes text toward the background while preserving token hues for review progress or noise reduction; on a transparent cell the tint is resolved against the background Hunk assumes rather than the one behind the terminal. `current` renders as reverse video, the `less`/vim convention for the active hit. |
There was a problem hiding this comment.
Overlong extension API paragraph
The expanded line-highlight documentation remains on one line far beyond the repository's 120-character limit, making this public API contract harder to review and maintain. Please wrap the paragraph to conform to the required formatting convention.
Context Used: guidelines.mdc Cursor rule (source)
Prompt To Fix With AI
This is a comment left during a code review.
Path: website/src/content/docs/docs/extend/extension-api.md
Line: 147
Comment:
**Overlong extension API paragraph**
The expanded line-highlight documentation remains on one line far beyond the repository's 120-character limit, making this public API contract harder to review and maintain. Please wrap the paragraph to conform to the required formatting convention.
**Context Used:** guidelines.mdc Cursor rule ([source](https://github.com/modem-dev/modem/blob/main/.cursor/rules/guidelines.mdc))
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Wrapped the paragraph to conform to the documentation line-length convention.
Responded by opencode using gemini-3.7-flash.
|
Thank you! This looks lovely in the extension. |
Resolves #852
Summary
Adds the
"dim"line highlight tone tohunkdiff/extension(registerLineHighlighter), the daemon protocol, and the agent session CLI. This enables review-progress workflows (e.g.,hunk-mark-as-reviewed), code coverage, and noise reduction by receding diff text toward the line background while preserving syntax token hues and guaranteeing minimum readable contrast.Key Details
span.fg) ~45% toward the line's effective background (contextBg,addedBg,removedBg, or word-diffemphasisBg), preserving individual keyword, string, number, and identifier colors rather than flattening text into a monochrome gray.MIN_DIM_TEXT_CONTRAST = 1.6with step-strengthening for low-contrast tokens/themes to ensure text remains legible across dark, light, and transparent themes.dimSpanFgCacheper(theme, baseBg, sourceFg, ratio)so subsequent renders resolve inHIGHLIGHT_TONES,protocol.ts,protocolSchemas.ts, andSessionHighlightAddCommandInputsupport--tone dim.Visual Preview
Live interactive mockup: https://sideshow.sh/p/wGMiKmQWjkM
Changes
ExtensionLineHighlightTonewith"dim".dimSpanFgandtransformFginsrc/ui/diff/rowStyle.tsandsrc/ui/diff/lineHighlightPaint.ts.rowStyle.test.ts,lineHighlightPaint.test.ts, andvalidate.test.ts..changeset/dim-line-highlighter-tone.md.