This produces the following keybind, which I believe was intended.
> keybind = cmd+backspace=text:\x15
Matches the cmd+left and cmd+right which are a few lines up.
#3679#3646
closes#2721
This PR resolves the issue where the Quick Terminal was not visible when
pressing the global keybind while a full-screen app was active.
### Changes
- Added new configuration options for `quick-terminal-space-behavior`
- The Quick Terminal will now overlay properly on top of full-screen
applications
#### Behavior
##### `quick-terminal-space-behavior = remain`
- The Quick Terminal will be remain open on the space when switching
spaces.
##### `quick-terminal-space-behavior = move`
- The Quick Terminal will be moved to active space when switching
spaces.
If the title is already the current working directory, hide the
subtitle. Otherwise show the current working directory, like if a
command is running for instance.
This is a re-opening of my original PR because I had to delete my fork
and re-fork it.
Fixes#4703
This changes `unbind` so it always removes all keybinds with the given
trigger pattern regardless of if it is translated or physical.
The previous behavior was technically correct, but this implements the pattern
of least surprise. I can't think of a scenario where you really want to
be exact about what key you're unbinding. And if that scenario does
exist, you can always fix it by rebinding after unbind.
If the title is already the current working directory, hide the
subtitle. Otherwise show the current working directory, like if
a command is running for instance.
Signed-off-by: Tristan Partin <tristan@partin.io>
Fixes#4509
Our config has a replay system so that we can make changes and reproduce
the configuration as if we were reloading all the files. This is useful
because it lets us "reload" the config under various conditions (system
theme change, etc.) without risking failures due to world state changing
(i.e. config files change or disappear).
The replay system assumed that all diagnostics were reproducible, but
this is not the case. For example, we don't reload `config-file` so we
can't reproduce diagnostics that come from it.
This commit adds a new `diagnostic` replay step that can be used to
store non-reproducible diagnostics and `config-file` is updated to use
it.
Also establishes a foundation for Wayland support and fixes a minor bug
(GTK windows remaining opaque when `background-opacity` is set to 1 on
startup and later updated to less than 1 with a config reload)
Can't update the Zig cache hash myself since I'm currently in China and
my proxy's broken for some reason :(
See also #4361, part of #4626
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).
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.
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).
closes#4328closes#3970
makes this possible now
```
keybind = performable:ctrl+c=copy_to_clipboard # copy if theres a selection else send sigint
keybind = ctrl+v=paste_from_clipboard
```
Closes https://github.com/ghostty-org/ghostty/issues/4089
Gave it a shot and implemented the custom css loading.
My general idea is to use a provider for each stylesheet the user wants
to load and then when the config changes unload them and create new
providers.
A separate provider has to be used for each stylesheet the user wants to
load, since when the provider loads the css it clears all the previously
loaded styles, so in effect we cannot use one provider to load multiple
stylesheets, but maybe there is a better way to overcome this limitation
which I'm not seeing.
The documentation used to say e.g. "The format of the color is the same
as the `background` configuration; see that for more information.", yet
`background` left the format actually undocumented.
To avoid people having to jump around the docs to find out the supported
formats, the prose for the formats is repeated for each color.
I dug around a bit to find out that named colors from the default X11
map are also a supported format (`cursor-color = purple` works fine), so
that's now documented too.
\+ much more flexible syntax and lenient parser
\+ allows comma-separated list as a single config value
This allows, e.g. `cv01 = 2` to select the second variant of `cv01`.
Resolves#3128
Parser could probably be a little smaller than it is- would be a lot
cleaner with the labeled switch continue pattern from Zig 0.14. Maybe
should've put it in its own file too...
I spent *much* too long trying to test this with `cv01` with
[monaspace](https://github.com/githubnext/monaspace) before realizing
that the README refers to v1.2 but the latest released version (and
hence the one I had installed) was v1.101 -- I installed the v1.2
version and tested with both CoreText and HarfBuzz and successfully set
`cv01 = 2` and got the expected result.
Feel free to make any stylistic changes you feel necessary before
merging.
When unset, we use Sparkle's default behavior, which is based on the
user's preference stored in the standard user defaults.
The rest of the previous behavior is preserved:
- When SUEnableAutomaticChecks is explicitly false, auto-updates are
disabled.
- When 'auto-update' is set, use its value to set Sparkle's auto-update
behavior.
Fixes#4433
