Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.68.1-dev OS Version: web Steps to Reproduce: a in to get editor gutter decorations for and changed lines. a file with a single line change e.g. a word in line 5. The line will show an indicator in the editor gutter for the changed line, which when clicked will open a Quick Diff peek view. a on the same line. The editor gutter will display the comment gutter icon (diamond inside rectangle), which when clicked will expand or collapse the comment on that line, and hide the indicator for the changed content in the same line, preventing the user from noticing that there is a change or opening Quick Diff to inspect it.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.69.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
With multi-line comments () the impact is likely higher. As the user is likely to make changes in close proximity to comments to address issues raised, this may disproportionately limit the utility of Quick Diff. cc
I'm not seeing them overlap: ! Am I looking at the correct thing?
That's the correct thing and in your screenshot it appears to be fine. Not sure why we are seeing the comment indicators draw over the change indicators, but we are also on a slightly older version and I am not sure if there are any other local adjustments in this space that I was not aware of. I will check this again on plain VS Code, sorry for the noise.
In 1.70.0-insider, I see this: for a multi-line change across the comment range: <img width="688" alt="Screen Shot 2022-07-26 at 16 06 34" src="https://user-"- for a single-line change on the same line as the comment range: <img width="715" alt="Screen Shot 2022-07-26 at 16 07 07" src="https://user-"This is for a simple Git repository, with a small test extension populating the comments. Caveat might be that it's "read-only" in the sense that I don't set , not sure if that causes problems? I see and draw in the same location and the comment thread wins because it has .
I suspect that not having the range provider is causing this. Will try to fix for July, but will likely move to August.
I tried setting a range provider, here are my observations: The docs for are wrong: When not provided, users cannot leave any comments—I think this is actually fine—and the gutter indicators overlap, as described. When setting a that returns for all documents, the behavior is the same as above. When setting a that returns , i.e. an empty range, the gutter indicators seem to draw correctly. However this also unexpectedly allows the user to start a discussion on line 1. For our extension, we don't want to support adding new comments on any lines, but otherwise show and allow replying to comments populated by the extension via the API. The reason is that our extension focuses primarily on supporting the author of a change / pull request in addressing the comments left by code reviewers in an external code review tool, i.e. they will almost never start a comment thread from their side. Allowing commenting on all lines of the file currently appears to draw an extremely distracting indicator through the entire gutter () which we strongly wish to avoid without requiring usage of Zen Mode. If the visuals of this were more subtle () we would not mind allowing users to comment on the entire file, even though it remains a rather rare use case for our user base.
The problem described in the original issue is a bug, which I will fix, You shouldn't need to have a commenting range provider at all. It sounds like there is also a doc bug, and an empty range bug, which I'll also look at. Regarding Zen mode: since the last update commenting is off by default in Zen Mode, so you shouldn't see any comments there. You can always toggle it back on with the command Comments: Toggle Editor Commenting.
The linked PR will fix the hidden decoration bug and the doc bug. I'm hesitant to make any changes for the range, as this may be intentional behavior or behavior that some extensions rely on.
I checked in Insiders today and this is now looking good for us, without setting . Thank you so much for the speedy fix!
marking as verified by author.

Related discussion:
text: /** * Optional commenting range provider. Provide a list {@link Range ranges} which support commenting to any given resource uri. * <del> * If not provided, users can leave comments in any document opened in the editor. </del> <ins> * If not provided, users cannot leave any comments. </ins> */ commentingRangeProvider?: CommentingRangeProvider;