cosmic-text crate of version 0.14.2
Zed uses COSMIC Text to lay out its editor lines on Linux: https://github.com/zed-industries/zed/blob/51b7d06a27780d007f8391ac7d05313611a27163/crates/gpui/src/platform/linux/text_system.rs#L378-L394
Similar things happen on other platforms, all of them have fn layout_line(&mut self, text: &str, font_size: Pixels, font_runs: &[FontRun]) -> LineLayout { as an "interface".
Here, &[FontRun] are based on internal metadata and are split the way Zed expects them to be split in the shaped text, for example, chunks of text with different colors produce different runs.
When Zed enabled bracket colorization (rainbow brackets), it starts to conflict with certain fonts' ligatures: >> and >>> are ligatures in many fonts (and when Zed is set to display them with calt = true font feature).
Zed needs the shape of the line only, hence does not send the color information when layouting the line — and all OS text systems seem to merge > > > font runs into a single glyph, positioned at the first >'s coordinates.
See zed-industries/zed#44254 for colorization examples, they look like ComplexType<..., >>.
Those are, in fact, not ligatures but brackets and are never meant to be a "bitwise shift operator ligature" to start with, and for sure we'd prefer not to merge the differently colored symbols into one.
For that, Windows and macOS do not provide any extra attributes, but do allow setting a font size attibute per run, and break shaping for different font sizes: so one can jitter the font size with the smallest increment to force logical font runs not being merged: zed-industries/zed#43080
Proposal: either Attrs attributes should get another field that prevents merging of adjacent runs, or alter the #257 further: the runs should consider metrics_opt when merging (and prevent merging for different font sizes) and should allow setting the font size only (to use whatever default line height in this case).
cosmic-text crate of version 0.14.2
Zed uses COSMIC Text to lay out its editor lines on Linux: https://github.com/zed-industries/zed/blob/51b7d06a27780d007f8391ac7d05313611a27163/crates/gpui/src/platform/linux/text_system.rs#L378-L394
Similar things happen on other platforms, all of them have
fn layout_line(&mut self, text: &str, font_size: Pixels, font_runs: &[FontRun]) -> LineLayout {as an "interface".Here,
&[FontRun]are based on internal metadata and are split the way Zed expects them to be split in the shaped text, for example, chunks of text with different colors produce different runs.When Zed enabled bracket colorization (rainbow brackets), it starts to conflict with certain fonts' ligatures:
>>and>>>are ligatures in many fonts (and when Zed is set to display them withcalt = truefont feature).Zed needs the shape of the line only, hence does not send the color information when layouting the line — and all OS text systems seem to merge
>>>font runs into a single glyph, positioned at the first>'s coordinates.See zed-industries/zed#44254 for colorization examples, they look like
ComplexType<..., >>.Those are, in fact, not ligatures but brackets and are never meant to be a "bitwise shift operator ligature" to start with, and for sure we'd prefer not to merge the differently colored symbols into one.
For that, Windows and macOS do not provide any extra attributes, but do allow setting a font size attibute per run, and break shaping for different font sizes: so one can jitter the font size with the smallest increment to force logical font runs not being merged: zed-industries/zed#43080
Proposal: either
Attrsattributes should get another field that prevents merging of adjacent runs, or alter the #257 further: the runs should considermetrics_optwhen merging (and prevent merging for different font sizes) and should allow setting the font size only (to use whatever default line height in this case).