Currently the `background` CSS class is added once on startup and never removed
or re-added. This is problematic as that if Ghostty was started with an opaque
window but then its config was reloaded with a `background-opacity` less than 1,
the window won't actually become translucent, and it would only appear as if the
background colors had become faded (because the window is still styled to be
opaque).
`:make` will call `ghostty +validate-config` and populate the quickfix
list with the errors that can be navigated to (e.g. with `:cnext`)
`:h write-compiler-plugin`, and neovim's built in ftplugin/ and
compiler/ plugins were used as references
Move the newly added *+insert keybinds to before the ctrl+shift+*
keybinds. This is needed to have the ctrl+shift keybinds be the ones
that show up in the menu.
Move the toast we send when copying to the clipboard to the Surface
implementation. Previously, we only called this from the gtk accelerator
callback which we only call when the *last set* keybind is activated.
We also only send a toast if we have copied to the standard clipboard,
as opposed to the selection clipboard. By default, we have
copy-to-clipboard true for linux, which sets the selection keyboard on
any select. This becomes *very* noisy.
Sorry for the vague title. This PR addresses multiple issues:
1. Fixes#4540
2. #4522 is fixed for macOS only
3. Fixes#4590
4. Fixes an untracked issue where `command+key` events will not send
release events for Kitty keyboard protocol, something I only noticed
while working on this.
There are multiple components to this PR.
## Part 1: `App/Surface.keyEventIsBinding`
This new API (also available in libghostty as
`ghostty_surface_key_is_binding`) returns a boolean true if the given
key event would match a binding trigger if it was the next key event
sent. It does not process the binding now.
This can be used by event handlers that intercept key events to
determine if it should send the event to Ghostty. This helps resolve
#4590 for us but is also part of all resolved issues.
## Part 2: macOS `performKeyEquivalent` changes
macOS calls `performKeyEquivalent` for any key combination that may
trigger a key equivalent. if this returns `true` then it is handled and
macOS ceases processing the event.
We were already using this to intercept things like `Ctrl+/` which
triggers a context menu in macOS Sequoia. But we now expand this to
intercept all events to check for bindings. This lets us fix#4590.
Additionally, it's been changed to special case `cmd+period`. I'm sure
more need to be added.
## Part 3: NSEvent local listener for command keyUp events
macOS simply doesn't send `keyUp` events for key events with command
pressed. The only way to work around this is to register an `NSEvent`
local listener. We now do this. This fixes the untracked issue noted
above.
This changes quit signaling from a boolean return from core app `tick()`
to an apprt action. This simplifies the API and conceptually makes more
sense to me now.
This wasn't done just for that; this change was also needed so that
macOS can quit cleanly while fixing #4540 since we may no longer trigger
menu items. I wanted to split this out into a separate commit/PR because
it adds complexity making the diff harder to read.
This changes quit signaling from a boolean return from core app `tick()`
to an apprt action. This simplifies the API and conceptually makes more
sense to me now.
This wasn't done just for that; this change was also needed so that
macOS can quit cleanly while fixing #4540 since we may no longer trigger
menu items. I wanted to split this out into a separate commit/PR because
it adds complexity making the diff harder to read.
In #4388, documentation was added for goto_split but in #3427 this
documentation was made outdated but not updated. This makes the
documentation up to date and brings the ordering in line with new_split
In #4388, documentation was added for goto_split but in #3427 this
documentation was made outdated but not updated. This makes the
documentation up to date and brings the ordering in line with new_split
This is achieved by rendering to an alpha-only context rather than a
normal single-channel context, and adjusting the brightness at which
coretext thinks it's drawing the glyph, which affects how it applies
font smoothing (which is what `font-thicken` enables).
Fixes#4518
If our UTF8 encoding is not recognized, we fall back to the ASCII
mapping of the logical key for the control sequence. This allows
cyrillic control characters to work.
I also verified that non-cyrllic (US) and alternate layouts (Dvorak)
work as expected still.
Fixes#4518
If our UTF8 encoding is not recognized, we fall back to the ASCII
mapping of the logical key for the control sequence. This allows
cyrillic control characters to work.
I also verified that non-cyrllic (US) and alternate layouts (Dvorak)
work as expected still.
When searching in the theme list (e.g., searching for "Snazzy"), some matching themes might be hidden due to incorrect window position handling.
This fix ensures all matching themes are visible by adjusting the window position logic.
Current sort used by `+list-keybinds` doesn't include the value of the
key:
```
ctrl + shift + v paste_from_clipboard
ctrl + shift + a select_all
...
ctrl + shift + q quit
ctrl + shift + n new_window
...
alt + five goto_tab:5
alt + eight goto_tab:8
...
alt + six goto_tab:6
alt + seven goto_tab:7
```
adding the key value improves the sort order
```
ctrl + shift + a select_all
ctrl + shift + c copy_to_clipboard
...
ctrl + shift + n new_window
ctrl + shift + o new_split:right
ctrl + shift + q quit
...
alt + one goto_tab:1
alt + two goto_tab:2
alt + three goto_tab:3
...
alt + eight goto_tab:8
alt + nine last_tab
alt + f4 close_window
