Keep the height reserved by a code mining in sync with the font - #4238
Merged
Conversation
Contributor
Test Results 858 files 858 suites 53m 10s ⏱️ Results for commit 80c3cf6. ♻️ This comment has been updated with latest results. |
vogella
force-pushed
the
codemining-font-change
branch
2 times, most recently
from
August 13, 2026 06:26
bc1e772 to
6f9bb4c
Compare
tobiasmelcher
approved these changes
Aug 13, 2026
tobiasmelcher
left a comment
tobiasmelcher
left a comment
Contributor
There was a problem hiding this comment.
Thanks a lot Lars for providing the fix.
vogella
force-pushed
the
codemining-font-change
branch
from
August 13, 2026 20:19
6f9bb4c to
2156451
Compare
A line header annotation reserves its vertical space while it is painted, so an annotation that is out of view keeps the space of the font it was last painted with. After the user changes the text size only the lines still in view take the new size, while the rest keeps the old spacing until something paints them again. Refresh the reserved height of every line header annotation that already reserves space when the line height of the text widget changes. SWT reports no font change, so it is noticed on the redraw the change triggers, comparing the line height rather than holding on to a font the editor disposes right after applying it.
vogella
force-pushed
the
codemining-font-change
branch
from
August 14, 2026 05:58
2156451 to
80c3cf6
Compare
Contributor
Author
|
Thanks @tobiasmelcher for the review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
A line header annotation reserves its vertical space while it is painted, so an annotation that is out of view keeps the space of the font it was last painted with. When the user changes the text size, only the lines still in view take the new size and everything else keeps the old spacing until it is scrolled into view. This is visible in any editor with multi-line line header minings, and it is what makes the experimental unified diff overlay update only partially on a zoom.
InlinedAnnotationSupportnow refreshes the reserved height of every line header annotation that already reserves space when the font of the text widget changes. SWT reports no font change, so it is noticed on the redraw that the change triggers, and lines that never reserved space keep reserving it lazily on their first paint as before.The new test in
CodeMiningTestfails without the fix, with line 5 still reserving 19 pixels after the line height grew to 37.