This fixes a couple of subtle rectangle select behaviors:
* Corrects how selection rolls over when crossing the x-boundary; this
was mentioned in #1021, this properly corrects it so both sides of the
x-boundary do not share characters.
* Corrects a minor quirk in the selection of initial cells in a
selection - this can be more readily observed when selecting a single
line with rectangle select. To correct this, we only use the x axis
when calculating this instead of both x and y.
This adds support for the equalize_splits feature that's already
implemented for macOS.
It's essentially a port of the Swift implementation, using the same
weights-mechanism to equalize split sizes.
terminfo and shell integration files can be installed on a headless server without copying all
of Ghostty to the server. Implementation liberally cribbed from the Kitty Nix package.
Further to the additional comments in #1055, this adds some references
to the comments in the ellipse algorithm (including the original
reference for the circle algorithm).
This changes the half-circle drawing algorithm for glyphs E0B4 and E0B6
to an ellipse algorithm.
This fixes a shortcoming in the circle approach - how do you handle
drawing for a box that is not a typical 2:1 H*W? We were trying to
anticipate this by taking the smaller of the two axes and using that for
the radius. This works when there's some error in the zoom and the x
radius somehow becomes larger than the y radius (in observation, this
happens occasionally in some zoom steps, but only slightly).
However, turns out a more realistic anticipation is for fonts that have
a much *larger* height-to-width ratio. Iosevka, for example, has an
approx. 2.6:1 ratio (observed in the inspector). In this instance, this
approach does nothing except lock the circle to an extremely small
radius. For this instance, we need an ellipse, which will handle all
cases in an expected fashion.
Fixes#1050.
Fixes#1037
Renderers must convert the internal Kitty graphics state to a GPU
texture for rendering. For performance reasons, renderers cache the GPU
state by image ID. Unfortunately, this meant that if an image was
replaced with the same ID and was already cached, it would never be
updated on the GPU.
This PR adds the transmission time to the cache. If the transmission
time differs, we assume the image changed and replace the image.
