This maybe is a robust way to get Monaspace fonts working.
Previously, we used leading as part of the calculation in cell height. I
don't remember why. It appears most popular monospace fonts (Fira Code,
Berkeley Mono, JetBrains Mono, Monaco are the few I tested) have a value
of 0 for leading, so this has no effect. But some fonts like Monaspace
have a non-zero (positive) value, resulting in overly large cell
heights.
The issue is that we simply add leading to the height, without modifying
ascent. Normally this is what you want (normal typesetting) but for
terminals, we're trying to set text centered vertically in equally
spaced grid cells. For this, we want to split the leading between the
top and bottom.
Instead of making a separate enum that must be translated from the
ClipboardRequest type, simply re-use ClipboardRequest to determine the
clipboard confirmation reason.
PR #850 introduced several color palette OSC setting and querying
sequencing. In doing so, an active palette was introduced to enable
resetting back to the default (configured) palette. The active palette
was not initialized with the configured palette, thus any configured
theme by the terminal was not set at launch.
This behavior can be confirmed thanks to PR #852, which resets the
active palette on configuration reload. To observe the behavior:
1. Set the configured palette to something other than the default
2. Open ghostty. Observe the color palette
3. Reload the configuration
4. Press enter for a new shell prompt. Note the palette has changed
This patch sets the configured palette as the active palette at
initialization.
When the config is changed, update the active palette in addition to the
default palette, but only those colors which have not been changed with
OSC 4.
Default colors are those set by the user in the config file, or an
actual default value if unset. The actual colors are modifiable and can
be changed using the OSC 4, 10, and 11 sequences.
Fixes#845
Quick background: Emoji codepoints are either default text or default
graphical ("Emoji") presentation. An example of a default text emoji
is ❤. You have to add VS16 to this emoji to get: ❤️. Some font are
default graphical and require VS15 to force text.
A font face can only advertise text vs emoji presentation for the entire
font face. Some font faces (i.e. Cozette) include both text glyphs and
emoji glyphs, but since they can only advertise as one, advertise as
"text".
As a result, if a user types an emoji such as 👽, it will fallback to
another font to try to find a font that satisfies the "graphical"
presentation requirement. But Cozette supports 👽, its just advertised
as "text"!
Normally, this behavior is what you want. However, if a user explicitly
requests their font-family to be a font that contains a mix of test and
emoji, they _probably_ want those emoji to be used regardless of default
presentation. This is similar to a rich text editor (like TextEdit on
Mac): if you explicitly select "Cozette" as your font, the alien emoji
shows up using the text-based Cozette glyph.
This commit changes our presentation handling behavior to do the
following:
* If no explicit variation selector (VS15/VS16) is specified,
any matching codepoint in an explicitly loaded font (i.e. via
`font-family`) will be used.
* If an explicit variation selector is specified or our explicitly
loaded fonts don't contain the codepoint, fallback fonts will be
searched but require an exact match on presentation.
* If no fallback is found with an exact match, any font with any
presentation can match the codepoint.
This commit should generally not change the behavior of Emoji or VS15/16
handling for almost all users. The only users impacted by this commit
are specifically users who are using fonts with a mix of emoji and text.
These sequences have been used "informally" forever, and until recently
mode 1004 was included in Xterm's XM (enable mouse reporting) sequence.
But as of ncurses 6.4 patch 20231028, focus reporting mode is removed
from XM and added to new fe and fd capabilities. Xterm also includes
definitions for the actual focus events ("kxIN" and "kxOUT"), so include
those too.
This tells AppKit to give the tab labels higher priority than the tab
titles. When the tabs become small, this causes the tab title text to be
truncated instead of dropping the tab label.
Fixes: https://github.com/mitchellh/ghostty/issues/843
