Update logic for generating `webgen_actions`.
Before the change, the following grouping was produced:
```md
## `copy_to_clipboard`
Copy and paste.
## `paste_from_clipboard`
## `paste_from_selection`
## `increase_font_size`
Increase/decrease the font size by a certain amount.
```
After the change, the following grouping is being produced
```md
## `copy_to_clipboard`
## `paste_from_clipboard`
## `paste_from_selection`
Copy and paste.
## `increase_font_size`
## `decrease_font_size`
Increase/decrease the font size by a certain amount.
```
Please note that this is my first time ever writing zig, so forgive me
violating zig best practices and feel free to make suggestions
Successor of [this](https://github.com/ghostty-org/website/pull/147) pr
in the website repo
Fixes#3117
On mouseExit we sent a cursor position event with (-1, -1). Negative
values are meant to indicate that the cursor is not on the surface. The
magnitude of the values are irrelevant. However, we never reset the
cursor position on mouseEnter.
This has the effect of the previous cursor position being stuck outside
the viewport which makes certain things such as `button` mouse reporting
not report until the mouse is moved.
This commit sends the correct cursor position event on mouseEnter.
Fixes#3117
On mouseExit we sent a cursor position event with (-1, -1). Negative
values are meant to indicate that the cursor is not on the surface. The
magnitude of the values are irrelevant. However, we never reset the
cursor position on mouseEnter.
This has the effect of the previous cursor position being stuck outside
the viewport which makes certain things such as `button` mouse reporting
not report until the mouse is moved.
This commit sends the correct cursor position event on mouseEnter.
Extracted from #3110
Initial fix is relatively basic, and catching it with a test only
required a little bit of extra scrutiny of the cursor state after one of
the tests that we already had.
However, the fix revealed faulty dirty tracking logic throughout the
`cursorScrollAbove` function (and therefore bad results that were being
tested for when they should not have been). I've ended up clarifying
things, fixing the asserted dirty states in all the `cursorScrollAbove`
tests, and then finally implementing another very trivial fix that
catches the mistake.
Fixing the dirty tracking is really just an exercise in correctness
though, since when the scroll happens it inherently invalidates the
viewport, and therefore will trigger a full rebuild in the renderer...
unless, I guess, another operation is performed that cancels things out
and results in the viewport pin being in the same place as the previous
render, but that seems an exceptionally difficult scenario to make
happen on purpose much less accidentally.
This PR is almost entirely changes to comments and tests, there are only
2 lines of real code it changes, the one added to the start of
`cursorScrollAbove` and the one modified at the start of
`cursorScrollAboveRotate`. I believe these changes are entirely safe. (I
wonder if they might have a bad effect on our `vtebench` scrolling
performance though...)
Extracted from #3110
A simple fix, with a unit test that covers the issue. This could cause
memory corruption and crashes in fairly realistic scenarios, since it
can occur whenever `cursorAbsolute` is used to move to a page that
happens to be at capacity for some form of managed memory and the cursor
is carrying some managed memory with it (style, hyperlink, etc.).
I really wish Zig had affine types so we could make `cursorChangePin`
"consume" its argument so it can't be accidentally used afterwards... I
think I'll audit the rest of the codebase anywhere we use
`cursorChangePin` to make sure we don't have similar problems.
Accounts for improved behavior due to prior memory corruption fix for
`cursorScrollAboveRotate` and reveals a new problem in a different
`cursorScrollAbove` sub-function.
Unless it's guaranteed that the new pin is in the same page as the old
one, `cursor.page_pin` should only be updated through `cursorChangePin`,
not directly.
We call `cursorChangePin` which may invalidate the provided pin if it
needs to adjust the page capacity, and as such we should consider the
pin we pass in to it invalid afterwards, and access it through cursor
instead.
Fixes#3119
Supersedes #3099
ConEmu and iTerm2 both use OSC 9 to implement different things. iTerm2
uses it to implement desktop notifications, while ConEmu uses it to
implement various OS commands.
Ghostty has supported iTerm2 OSC 9 for a while, but it didn't (and
doesn't) support ConEmu OSC 9. This means that if a program tries to
send a ConEmu OSC 9 to Ghostty, it will turn into a desktop
notification.
This commit adds parsing for ConEmu OSC 9 progress reports. This means
that these specific syntaxes can never be desktop notifications, but
they're quite strange to be desktop notifications anyway so this should
be an okay tradeoff.
This doesn't actually _do anything with the progress reports_, it just
parses them so that they don't turn into desktop notifications.
cc @Jan200101
Fixes#3119
ConEmu and iTerm2 both use OSC 9 to implement different things. iTerm2
uses it to implement desktop notifications, while ConEmu uses it to
implement various OS commands.
Ghostty has supported iTerm2 OSC 9 for a while, but it didn't (and
doesn't) support ConEmu OSC 9. This means that if a program tries to
send a ConEmu OSC 9 to Ghostty, it will turn into a desktop notification.
This commit adds parsing for ConEmu OSC 9 progress reports. This means
that these specific syntaxes can never be desktop notifications, but
they're quite strange to be desktop notifications anyway so this should
be an okay tradeoff.
This doesn't actually _do anything with the progress reports_, it just
parses them so that they don't turn into desktop notifications.
Fixes#3114
I forgot that the format gets parsed as a Zig string so putting it in
already parsed made `+list-keybinds` incorrect. It worked either way but
this fixes the `+list-keybinds` CLI action.
Fixes#3114
I forgot that the format gets parsed as a Zig string so putting it in
already parsed made `+list-keybinds` incorrect. It worked either way but
this fixes the `+list-keybinds` CLI action.
A follow-up on #3103, the `Style.eql` function can also benefit from
`PackedStyle`.
Using the same DFZ benchmark,
New: 795 FPS
Old (fddedd7c): 765 FPS
FPS is a bit different due to differing background system loads, but the
increase in FPS is consistent across benchmarks.
# Description
This commit introduces the ability to launch the quick terminal in the
middle position.
## Note to reviewer
- The quick terminal is currently centered. Should we consider adding a
top offset to better align with the screenshot in [the issue](#2494 )?
Should it be configurable?
- On large monitors, half the visible frame might be excessively large.
To mitigate, I am planning to implement #2384 but we should probably
agree on a good default maximum width/height in middle position.
- I also figured out, reloading the configuration does not update the
quick terminal configuration. That is also an issue I will try to fix.
Resolves#2494
I agree to relicense my commit to MIT.
Fixes#3106
Related to #2838
Discussion in #2363
This breaks fixterms encodings for these specific keys so that shells
and other programs that rely on the legacy encoding for these keys will
work by default.
This only does this for macOS because for whatever reason during the
large beta period, only macOS users found this as lacking.
If users want to restore fixterms behaviors, they can rebind these keys
as `unbind`.
Fixes#3106
Related to #2838
Discussion in #2363
This breaks fixterms encodings for these specific keys so that shells
and other programs that rely on the legacy encoding for these keys will
work by default.
This only does this for macOS because for whatever reason during the
large beta period, only macOS users found this as lacking.
If users want to restore fixterms behaviors, they can rebind these keys
as `unbind`.
…port
...unless ~/.config/ghostty/config already exists, then that is opened.
(Or whatever $XDG_CONFIG_HOME points to.)
If both files exists, ghostty reads first the one in
~/.config/ghostty/config and then the one in Application Support, and
merges the settings. In that case, the menu item opens the file at
~/.config.
Fixes#2890.
The idea is to serialize `Style` into a packed format as quickly as
possible.
Following an SOA pattern here yields the best result.
Using the Doom-Fire benchmark,
New: 780FPS
Old (f46a6769): 627FPS
Memory usage isn't affected as the layout changes cancel each other out.
