gpui: Fix ascent/descent calculation on macOS (#39886)
Bennet Bo Fenner
created
As you can see in the image, we were previously returning different
`ascent`s/`descent`s when a line would/would not contain an Emoji.
<img width="104" height="36" alt="image"
src="https://github.com/user-attachments/assets/436aeda0-87c0-4dee-943b-6da83681d466"
/>
---
CoreTexts `CTLineGetTypographicBounds` seems to return a different
ascent/descent depending on if an Emoji is there or not AFAIK it is not
documented if this is intended behaviour or not. For us it is
undesirable, as typing an Emoji causes the line to be shifted to the
bottom, see here:
https://github.com/user-attachments/assets/2ad1c82e-6297-48ac-a522-fb382ea56eea
---
Instead of using `CTLineGetTypographicBounds` to resolve the
ascent/descent, we look at every run and choose the maximum
ascent/descent. This matches how it [works on
Linux](https://github.com/zed-industries/zed/blob/f1d17fcfbef41690fdeb523f0fbddc7c406c5ad6/crates/gpui/src/platform/linux/text_system.rs#L452)
Release Notes:
- Fixed an issue on macOS where typing an emoji on a line would cause
the line to shift downwards by a few pixels