Fix cell formatting issues #754
Conversation
lionel-
force-pushed
the
bugfix/vscode-format-cell
branch
from
8c9747e to
0902ef2
Compare
| edits.forEach((edit) => { | ||
| editBuilder.replace(edit.range, edit.newText); | ||
| }); | ||
| // Sort edits by descending start position to avoid range shifting issues |
There was a problem hiding this comment.
Unrelated but I thought we should make this robust to providers returning unsorted edits.
|
|
||
| // Bail if any edit is out of range. We used to filter these edits out but | ||
| // this could bork the cell. | ||
| if (edits.some(edit => !blockRange.contains(edit.range))) { |
There was a problem hiding this comment.
Unrelated but I'm pretty sure applying edits partially can bork our cells 😬
|
Thanks for the PR! Something for us to consider: Every time I see a PR here I get a feeling of dread: we have no test coverage and so I have very little visibility or intuition of the impact that these changes make. What kind of infrastructure would we have to add for us to have unit test coverage for these kinds of changes? |
|
Part of the reason this is still a draft is that I'd like to add some tests here. They'll be limited in scope though. Here are the levels of tests we have in our R stack, by ascending level of scope:
We spend most of our time and energy on internal LSP tests. |
Addresses #745
But needs to be tested more widely and deal with formatters that don't ensure a trailing newline as discussed in #745 (comment).