Skip to content

Conversation

lionel-
Copy link
Collaborator

@lionel- lionel- commented Jul 4, 2025

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).

@lionel- lionel- marked this pull request as draft July 4, 2025 10:36
@lionel- lionel- force-pushed the bugfix/vscode-format-cell branch from 8c9747e to 0902ef2 Compare July 4, 2025 10:52
edits.forEach((edit) => {
editBuilder.replace(edit.range, edit.newText);
});
// Sort edits by descending start position to avoid range shifting issues
Copy link
Collaborator Author

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))) {
Copy link
Collaborator Author

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 😬

Copy link
Collaborator

@vezwork vezwork Sep 4, 2025

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:

Screenshot 2025-09-04 at 12 12 30 PM

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.

@cscheid
Copy link
Contributor

cscheid commented Jul 7, 2025

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?

@lionel-
Copy link
Collaborator Author

lionel- commented Jul 7, 2025

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.

@vezwork
Copy link
Collaborator

vezwork commented Sep 2, 2025

@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!

@juliasilge
Copy link
Collaborator

@vezwork It turns out that @lionel- is OOO all this week. I think an extension test that formats and checks the contents is a great way to go, and if you are wanting to work on this soon-ish (before conf) I am happy to review if you can contribute a test or two!

@vezwork
Copy link
Collaborator

vezwork commented Sep 4, 2025

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:

Screenshot 2025-09-04 at 12 12 30 PM

I was able to reproduce #745 in Positron on the main branch of the extension, so this error is confirmed to be caused by this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants