gpui: Do not render ligatures between different styled text runs#39928
Merged
gpui: Do not render ligatures between different styled text runs#39928
Conversation
) Currently when we render text with differing styles adjacently we might form a ligature between the text, causing the ligature forming characters to take on one of the two styles. This can especially become confusing when a ligature is formed between actual text and inlay hints. Annoyingly, the only ways to prevent this with core text is to either render each run separately, or to insert a zero-width non-joiner to force core text to break the ligatures apart, as it otherwise will merge subsequent font runs of the same fonts. We currently do layouting on a per line basis and it is unlikely we want to change that as it would incur a lot of complexity and annoyances to merge things back into a line, so this goes with the other approach of inserting ZWNJ characters instead. Note that neither linux nor windows seem to currently render ligatures, so this only concerns macOS rendering at the moment. Release Notes: - Fixed ligatures forming between real text and inlay hints on macOS
8a9b914 to
3b9dbf3
Compare
mikayla-maki
added a commit
that referenced
this pull request
Oct 22, 2025
Fixes a bug in #39928 The bug caused all completions to appear in bold-face Release Notes: - Fixed a bug where bold-face font was applied to the wrong characters in items in the autocomplete menu Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
mikayla-maki
added a commit
that referenced
this pull request
Oct 22, 2025
Fixes a bug in #39928 The bug caused all completions to appear in bold-face Release Notes: - Fixed a bug where bold-face font was applied to the wrong characters in items in the autocomplete menu Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Veykril
added a commit
that referenced
this pull request
Oct 23, 2025
Member
|
Uh, I don't love that |
cyndis
added a commit
to cyndis/zed
that referenced
this pull request
Nov 27, 2025
After zed-industries#39928, if a font's weight changes between text runs without other decoration changing, the earlier weight continues to be used for the subsequent run(s). PR zed-industries#40840 fixes this in shape_text, but similar code exists also in layout_text. The latter is used for text in the editor view itself, so the issue continues to appear when using a highlighting theme with varied font weights. Fix the issue by applying the same fix in layout_text.
Veykril
pushed a commit
that referenced
this pull request
Dec 1, 2025
After #39928, if a font's weight changes between text runs without other decoration changing, the earlier weight continues to be used for the subsequent run(s). PR #40840 fixes this in shape_text, but similar code exists also in layout_text. The latter is used for text in the editor view itself, so the issue continues to appear when using a highlighting theme with varied font weights. Fix the issue by applying the same fix in layout_text. Closes #42297 Release Notes: - Fixed incorrect font weights in editor view when using a highlighting theme with varying font weights
github-actions bot
pushed a commit
that referenced
this pull request
Dec 5, 2025
After #39928, if a font's weight changes between text runs without other decoration changing, the earlier weight continues to be used for the subsequent run(s). PR #40840 fixes this in shape_text, but similar code exists also in layout_text. The latter is used for text in the editor view itself, so the issue continues to appear when using a highlighting theme with varied font weights. Fix the issue by applying the same fix in layout_text. Closes #42297 Release Notes: - Fixed incorrect font weights in editor view when using a highlighting theme with varying font weights
zed-zippy bot
added a commit
that referenced
this pull request
Dec 5, 2025
…erry-pick to stable) (#44197) Cherry-pick of #43856 to stable ---- After #39928, if a font's weight changes between text runs without other decoration changing, the earlier weight continues to be used for the subsequent run(s). PR #40840 fixes this in shape_text, but similar code exists also in layout_text. The latter is used for text in the editor view itself, so the issue continues to appear when using a highlighting theme with varied font weights. Fix the issue by applying the same fix in layout_text. Closes #42297 Release Notes: - Fixed incorrect font weights in editor view when using a highlighting theme with varying font weights Co-authored-by: Mikko Perttunen <cyndis@kapsi.fi>
someone13574
pushed a commit
to someone13574/zed
that referenced
this pull request
Dec 16, 2025
…ies#43856) After zed-industries#39928, if a font's weight changes between text runs without other decoration changing, the earlier weight continues to be used for the subsequent run(s). PR zed-industries#40840 fixes this in shape_text, but similar code exists also in layout_text. The latter is used for text in the editor view itself, so the issue continues to appear when using a highlighting theme with varied font weights. Fix the issue by applying the same fix in layout_text. Closes zed-industries#42297 Release Notes: - Fixed incorrect font weights in editor view when using a highlighting theme with varying font weights
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.
This relands #37175 as #39886 fixed the jiggling issue.
Currently when we render text with differing styles adjacently we might form a ligature between the text, causing the ligature forming characters to take on one of the two styles. This can especially become confusing when a ligature is formed between actual text and inlay hints.
Annoyingly, the only ways to prevent this with core text is to either render each run separately, or to insert a zero-width non-joiner to force core text to break the ligatures apart, as it otherwise will merge subsequent font runs of the same fonts.
We currently do layouting on a per line basis and it is unlikely we want to change that as it would incur a lot of complexity and annoyances to merge things back into a line, so this goes with the other approach of inserting ZWNJ characters instead.
Note that neither linux nor windows seem to currently render ligatures, so this only concerns macOS rendering at the moment.
Closes #23194
Release Notes: