-
-
Notifications
You must be signed in to change notification settings - Fork 207
fix: add range offset for insertion suggestion #768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
WalkthroughreportDifference in Changes
Sequence Diagram(s)sequenceDiagram
participant Linter
participant reportDifference
participant Fixer
Linter->>reportDifference: provide offset, deleteText, insertText
reportDifference->>reportDifference: highlightStart = offset
reportDifference->>reportDifference: highlightEnd = offset + (deleteText.length || min(insertText.length,1))
reportDifference->>reportDifference: replaceRange = [offset, offset + deleteText.length]
reportDifference->>reportDifference: loc = getLocFromIndex(sourceCode, highlightStart/End)
reportDifference->>Fixer: register fix using replaceRange
Fixer-->>Linter: fix applied or suggested
note right of reportDifference #DFF7DF: highlight window may expand for insertions\nfixer uses dedicated replace range
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important
Looks good to me! 👍
Reviewed everything up to 69b4661 in 2 minutes and 6 seconds. Click for details.
- Reviewed
36lines of code in1files - Skipped
0files when reviewing. - Skipped posting
2draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. eslint-plugin-prettier.js:109
- Draft comment:
Prefer using a ternary (insertText.length ? 1 : 0) for clarity instead of Math.min(insertText.length, 1). - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
2. eslint-plugin-prettier.js:125
- Draft comment:
Ensure that adding the ghost offset (end + insertSuggestionOffset) does not exceed the source text length. Consider clamping the index if the suggestion is at the very end of the file. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is making a speculative suggestion about potential bounds checking. The diff shows thatinsertSuggestionOffsetis at most 1 (fromMath.min(insertText.length, 1)), so we're adding at most 1 toend. Theendvalue comes fromoffset + deleteText.length, which should be valid indices from the difference calculation. Without seeing evidence thatgetLocFromIndexfails on out-of-bounds indices, or that the difference calculation can produce invalid offsets, this seems speculative. The comment uses "Consider" language which suggests uncertainty. According to the rules, I should not keep speculative comments that say "If X, then Y is an issue" - only if it's definitely an issue. I might be missing that ESLint'sgetLocFromIndexor the ponyfill implementation could fail or produce incorrect results with out-of-bounds indices. The ponyfill implementation shown doesn't have explicit bounds checking, so passing an index beyond the text length might produce unexpected results. While the ponyfill might not have explicit bounds checking, there's no evidence in the diff that this is actually causing a problem or that the indices being passed would ever be out of bounds. The difference objects should come from valid text comparisons. This remains a speculative concern without concrete evidence of failure. This comment is speculative and uses "Consider" language without demonstrating that there's an actual bug. It suggests defensive programming but doesn't show strong evidence that the issue occurs. According to the rules, speculative comments should be removed.
Workflow ID: wflow_8LTebGtVsneEozlD
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
eslint-plugin-prettier.js(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: dotcarmen
PR: prettier/eslint-plugin-prettier#743
File: eslint-plugin-prettier.js:0-0
Timestamp: 2025-06-14T15:04:53.678Z
Learning: In the getLocFromOffset function for eslint-plugin-prettier.js, the correct implementation uses `const withSentinel = [-1, 0, ...lineIndexes]` to create an array of line start positions without variable shadowing, and calculates column as `offset - withSentinel[line]` without additional offsets.
📚 Learning: 2025-06-14T15:04:53.678Z
Learnt from: dotcarmen
PR: prettier/eslint-plugin-prettier#743
File: eslint-plugin-prettier.js:0-0
Timestamp: 2025-06-14T15:04:53.678Z
Learning: In the getLocFromOffset function for eslint-plugin-prettier.js, the correct implementation uses `const withSentinel = [-1, 0, ...lineIndexes]` to create an array of line start positions without variable shadowing, and calculates column as `offset - withSentinel[line]` without additional offsets.
Applied to files:
eslint-plugin-prettier.js
🔇 Additional comments (1)
eslint-plugin-prettier.js (1)
124-127: Verify boundary handling and REPLACE operation behavior.The concern about boundary handling when
offsetis at the end of the file is valid. Analysis reveals:
insertSuggestionOffsetisMath.min(insertText.length, 1), so it's either 0 or 1- When an INSERT operation occurs at the end of file,
loc.endbecomesgetLocFromIndex(sourceCode, sourceCode.text.length + 1), which is out of bounds- The
getLocFromIndexponyfill clamps to the last line and returns a column value equal to(out-of-bounds-index) - (last-line-start), which can exceed the actual line length- No tests currently exist for INSERT, DELETE, or REPLACE operations, including boundary cases
While ESLint may accept such positions, this behavior should be explicitly tested to confirm it doesn't cause issues in editors or downstream tools. Additionally, if REPLACE operations intentionally extend the location range beyond deleted text (as mentioned in the original comment), this should be clarified and tested.
The issue has started from there: zed-industries/zed#41049
The editor receives a zero range when characters from prettier need to be added. This causes the dropdown menu with actions (fixes) to work incorrectly. I added 1 "ghost" offset index, now it works properly (see video below).
Screen.Recording.2025-10-30.at.13.45.26.mov
Important
Adds a 'ghost' offset in
reportDifference()ineslint-plugin-prettier.jsto fix dropdown menu behavior for insertion suggestions.reportDifference()ineslint-plugin-prettier.js.insertTextis present, ensuring correct dropdown menu behavior.reportDifference()to calculateendwithinsertSuggestionOffset.getLocFromIndex()to determinestartandendpositions with the new offset.This description was created by
for 69b4661. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit