-
Notifications
You must be signed in to change notification settings - Fork 29.4k
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
Provide diff view inside comment card to preview suggested edits #192129
Comments
We have the same need in the GitHub Pull Request and Issues extension, so this is something that we would like to have in our codebase. Given the current comment API, did you have some idea how we could add this? |
The two obvious places are connecting it either to the Regarding the data structure I see two main options we have:
While editing the code these edits might become stale so we need to decide how we want to handle updating this preview:
Looking at these options I think having a Also a note on the implementation of the preview itself: As we potentially can have lots of these edit previews showing at the same time we need to be mindful about resources here. That's why it's probably too costly to just spin up new editor instances in the preview. Unsure if there is already something slim enough we could reuse or if it would be best to have a new component for this. |
@JonasMa thanks for the reply and for your patience waiting for my response! I'm going to get designing the API for this feature on our October plan so that I can devote time to helping create a good API for you to help implement. I should be able to take a good look at your proposal and write a proper reply next week. |
@JonasMa would a simple markdown based approach work for you? GitHub uses the following markdown syntax to indicate a suggestion: Then, it uses the lines that the comment applies to as the left of the diff, and the lines within the For your purposes, does a suggestion always apply only to the lines that a comment applies to? |
@JonasMa I would be happy to accept a PR for the behavior outlined in #192129 (comment). |
Also @laurentlb and @hermannloose. |
Sorry for the late reply. Laurent, Hermann and me aren't working on this project anymore. |
How do we keep momentum on this going during this transition? We will definitely need this at some point. |
@poucet, once you're looking at this again just ping in this issue and I'll see if I have cycles at that time to provide pointers and discuss the problem. If I don't have cycles, then I'll try to get it on our next iteration plan (we run monthly iterations). Assuming the proposal I made in #192129 (comment) works for you then you shouldn't need too much assistance from me to be able to make a PR. |
The problem with a markdown approach is it assumes that all code review systems use the same GitHub syntax. From a quick search, GitLab has something similar but slightly different (https://docs.gitlab.com/ee/user/project/merge_requests/reviews/suggestions.html) where you can specify line offsets. With our system, suggested edits are not included in the comment, but are stored as metadata with the comment.
Unfortunately not, for example you might comment the line Also, with the GitLab example, their We already have the concept of edits coming from extensions, perhaps it would be best to allow comment providers to pass in edits explicitly, and then it is up to the implementation wrt how suggestions are transmitted. Basically just offloading the conversion of markdown blocks to edits to the extensions, but keeping the rest of the code the same? |
A comment providing extension can always modify the comment body before handing it to VS Code to display (GitHub Pull Requests and Issues does a lot of this to linkify usersnames and have better rendering for permalinks and suggestions), so I don't think this alone prevents the markdown approach. We can define our own suggestion syntax for this, which could even include an optional offset like GitLab has.
In this case, what would the visual representation of the diff in the comment widget show? |
Hi, Sorry, this got a bit lost over Christmas. Assuming this is still an open issue.
I think my question is that extensions will need to parse the comment structure from the service they talk with, and will then have the diff stored somehow in memory. It seems odd to then encode that back into Markdown for VS Code to then pull a |
Proposal: Inline Diff Previews for Comment Cards APIOur team is keen to improve the code review experience in VS Code, especially for comments with suggested edits. We propose adding inline diff previews directly within comment cards, providing a quick, visual way to assess and apply changes without leaving the review flow. This approach aligns with ICSE-SEIP'23 paper, "Towards More Effective AI-Assisted Programming: A Systematic Design Exploration to Improve Visual Studio IntelliCode's User Experience". See the paper or Summary for more details. Why This Matters
What is wrong with the current comment card?Based on user feedback, we identified the following pain points:
The concept
[1] Gutter icon: Appear next to the line number Figma with card variants and Nomenclature (Pass: GooG24*) PrototypeDesign Principles based on the paper
Implementation ProposalWe propose modifying the Comments API to allow comment providers to include a structured diff along with the comment text. This will enable the display of inline diff previews within the comment card itself. The API can be used for various types of comments, including human comments, automatically detected issues, and potential test results during code review time. Next Steps
Let us know your thoughts and how we can move forward together! |
@daviddossett Hi David, here's the proposal we had discussed last time we chatted. Feel free to take a look and we're happy to answer questions or clarify |
In our code review process at Google we're able to provide suggested edits as a reviewer. Currently we're trying to include these suggestions better in our review flow. We think an inline preview to smaller code suggestions in the comment card will be a very helpful tool for the code author. This could look something like this:
While this looks a lot like an integrated peek view I'd expect some memory issues when displaying lots of them at the same time. That's why I think this would need to be a bit more custom.
I could see this being useful for all users, not only inside our organisation.
What do you think? Is this a feature you could imagine having in your code base?
If so we could imagine to help implement it.
The text was updated successfully, but these errors were encountered: