feat(autoedits): Correctly produce decorations for files that use Tab indentation #6617
Conversation
| const text = blockify(mockSpacesDocument, mockAddedLines).map(({ lineText }) => lineText).join('\n') | ||
| expect(text).toMatchInlineSnapshot(` | ||
| "hello world | ||
| goodbye world" | ||
| `) |
There was a problem hiding this comment.
Kinda wish GitHub rendered special characters differently... these tests are a lot nicer like this:
umpox
force-pushed
the
tr/auto-edits-tab
branch
from
e4a2003 to
7805329
Compare
💜 |
|
|
||
| export const UNICODE_SPACE = '\u00A0' | ||
|
|
||
| export function blockify( |
There was a problem hiding this comment.
Could you add a doc string comment with a simple input -> output example explaining what this function does? I understand it from looking at the test cases, but it's still an obscure function name. It should help us with reading this code later.
| import { blockify } from './blockify' | ||
| import type { AddedLinesDecorationInfo } from './default-decorator' | ||
|
|
||
| describe('blockify', () => { |
| } | ||
|
|
||
| // For files using tab-based indentation, we need special handling. | ||
| // VSCode's Range API doesn't account for tab display width |
There was a problem hiding this comment.
Does it mean that if tabs are used, the column number we get is lower because it counts every tab for one char instead of tabSize?
| private renderAddedLinesDecorations( | ||
| addedLinesInfo: AddedLinesDecorationInfo[], | ||
| _addedLinesInfo: AddedLinesDecorationInfo[], |
There was a problem hiding this comment.
Why do we want to prefix with _ here?
| @@ -231,6 +231,20 @@ test('autoedits: triggers inline decorations when multiple separate insertions a | |||
| }) | |||
| }) | |||
|
|
|||
| test('autoedits: triggers a suffix decoration and renders correctly in files that use tab based indentation', async ({ | |||
Description
closes https://linear.app/sourcegraph/issue/CODY-4651/fix-uneven-spacing-in-suffix-decorations
Our suffix decorations were broken in a number of ways for files that used Tab indentation:
line.range.end.charactermatched the column position where we want to render the decoration. This is not correct, and the more tabs on a line the more out of position the decoration would be come. We ran into a similar issue with our command hint decorations.This PR:
replacerColby taking into account the space/tab based indentation and the indentation amountblockifylogic so we're not longer modifying the existing data structure (hard to understand if this could trigger side effects) and instead we return a new structureblockifyBefore
After
Test plan