-
Notifications
You must be signed in to change notification settings - Fork 42
Fix cell formatting issues #754
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated but I'm pretty sure applying edits partially can bork our cells 😬
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.
I pulled down this PR, rebased on main, and followed the reproduction steps in #745 (which this PR should address). I ran into a new error that prevented any formatting from occuring:

I reverted this code change locally (bailing if edits are out of range) and formatting works again and the problem described in #745 is addressed.
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. |
@lionel- we now have extension tests! The tests are focused on roundtripping right now, but they do already involve executing commands. Do you think an extension test (a snapshot test?) that opens our test qmd files, executes the format command, and checks the contents of the file would provide enough coverage for this PR? I'd like to get this PR in, so I'm happy to write the tests. Please advise! |
I pulled down this PR, rebased on main, and followed the reproduction steps in #745 (which this PR should address). I ran into a new error that prevented any formatting from occuring: ![]() I was able to reproduce #745 in Positron on the |
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).