editor: Fix inline Git blame not visible on long lines due to overflow #23374
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #18702
This is take 2 of my previous PR, which was closed due to inactivity and merge conflicts.
Cause:
The editor's horizontal scroll width only considers the longest line in the buffer, using
layout_line
forlongest_row
. The inline blame width isn’t included in it because it is just a decoration on top of the line (think of like CSS absolute) and not part of its actual content. This causes blame to overflow.Solution:
Along with
longest_row
width we also add that line's inline blame width for scroll width calculation. We also have to add some padding that is between inline blame and line's content.Alternate Solution:
In my previous PR, instead of adding the inline blame width of the longest line for scroll width calculation, I used the inline blame of the current line the cursor is on (since we only see the blame for the current line). I added that to the current line's width, giving us the full width of that row. Then, we compare that row's width with the longest row width and use the max of the two for the scroll width calculation.
While this solution seems clever, it's overly complicated and could cause issues, like the scroll width changing every time you move the cursor up or down. I don't think we should go with this, but I'm open to suggestions.
Preview:
Before:
before.mp4
After:
after.mp4
Release Notes: