See: https://github.com/ziglang/zig/issues/17851
Users were noticing that frame render times got slower over time. I
believe (thanks to community for pointing it out) that this is the
culprit.
This works around this issue by clearing and reinitializing the LRU
after a certain number of evictions. When the Zig issue has a better
resolution (either rehash() as a workaround or a better hash
implementation overall) we can change this.
Fixes#1771
I'm not convinced this fix won't regress some other behavior, but in my
titlebar tab and native tab modes with and without transparency, this
has looked okay to me.
When the -c option is present, then commands are read from the first
non-option argument command string. Our simple implementation assumes
that if we see at least the '-c' option, a command string was given, and
the shell is always considered to be non-interactive - even if the '-i'
(interactive) option is also given.
Fixes#1409
Fixes macOS 14.4,14.5 kernel panics
As noted in the comment in this diff, I've decided to default this to
true because it fixes a couple _really bad_ issues for macOS users. For
macOS users on 14.4 and 14.5 (latest released as of this commit), this
resolves or at least heavily mitigates a possible kernel panic.
This also fixes#1409 where external displays over certain connections
such as DisplayLink would be unusably slow to render.
Partial fix for link highlight dirty tracking. Some issues remain with
soft-wrapped links (see TODO in code), as well as pressing cmd while
hovering without moving the mouse at all doesn't highlight until you do
move the mouse for some reason.
Fixes#1756
We previously converted from view to screen coordinates but if the view
doesn't take up the full window then the view coordinates are wrong. We
need to convert to window coordinates in the middle.
When hot reloading config with a new font, shaper cache data needs to be
invalidated and the font grid needs to be rebuilt. This change just
makes that happen on all config reloads since it's a rare action so it's
not a performance concern.
I make the following suggestion through a PR since I already tried this locally and have a branch ready:
- Rename Split Horizontally to Split Right
- Rename Split Vertically to Split Down
Rationale:
The terms horizontal and vertical are ambiguous in the context of splitting (does it mean the splitter is vertical, or are the panes organized vertically?)
Different apps pick different interpretations, so people get confused.
IntelliJ made the same change as above based on user feedback: https://youtrack.jetbrains.com/issue/IJPL-130991/Split-Vertically-and-Split-Horizontally-are-ambiguous-and-should-be-renamed
Ghostty is using the left/right nomenclature in other menu items. In the codebase, SplitDirection is already left/right.
