The major idea behind the refactor is to split the `build.zig` file up into
distinct `src/build/*.zig` files. By doing so, we can improve readability of
the primary `build.zig` while also enabling better reuse of steps. Our
`build.zig` is now less than 150 lines of code (of course, it calls into a lot
more lines but they're neatly organized now).
Improvements:
* `build.zig` is less than 150 lines of readable code.
* Help strings and unicode table generators are only run once when multiple
artifacts are built since the results are the same regardless of target.
* Metal lib is only built once per architecture (rather than once per artifact)
* Resources (shell integration, terminfo, etc.) and docs are only
built/installed for artifacts that need them
Breaking changes:
* Removed broken wasm build (@gabydd will re-add)
* Removed conformance files, shell scripts are better and we don't run
these anymore
* Removed macOS app bundle creation, we don't use this anymore since we
use Xcode
## Some History
Our `build.zig` hasn't been significantly refactored since the project started,
when Zig was _version 0.10_. Since then, the build system has changed
significantly. We've only ever duct taped the `build.zig` as we needed to
support new Zig versions, new features, etc. It was a mess.
The major improvement is adapting the entire Ghostty `build.zig` to the Step
and LazyPath changes introduced way back in Zig 0.12. This lets us better take
advantage of parallelism and the dependency graph so that steps are only
executed as they're needed.
As such, you can see in the build.zig that we initialize a lot of things, but
unless a final target (i.e. install, run) references those steps, _they'll
never be executed_. This lets us clean up a lot.
**Overview**: add support for file paths starts with `../` `./` and `/`
To implement this I extended the existing regex variable in the
`src/config` dir. In a few test cases, extra space is added
intentionally to verify we don't include space in the URL as it looks &
feels odd.
Here is the text file content used for testing
```console
➜ ~ cat test.txt
https://google.com
file:///Users/ABC/oss/ghostty/build.zig
file:///Users/ABC/oss/ghostty/debug.sh
/Users/ABC/oss/ghostty/src/../debug.sh
../../Applications/Zed.app/Contents/Info.plist
[link](/home/user/ghostty.user/example) -- non-existent
[link](/Users/ABC/oss/ghostty/src/../debug.sh)
first time ../../Applications/Zed.app/Contents/Info.plist contributor
➜ ~
```
Here is the screen recording of the changes.
[](https://www.youtube.com/watch?v=Q8qdwdBVbWk)
Related to #4485
This commit matches ConEmu's parsing logic[^1] more faithfully. For any
substate that requires a progress, ConEmu parses so long as there is a
number and then just ignores the rest.
For substates that don't require a progress, ConEmu literally ignores
everything after the state.
Tests cover both.
[^1]:
740b09c363/src/ConEmuCD/ConAnsiImpl.cpp (L2264)
Related to #4485
This commit matches ConEmu's parsing logic[^1] more faithfully. For any
substate that requires a progress, ConEmu parses so long as there is a
number and then just ignores the rest.
For substates that don't require a progress, ConEmu literally ignores
everything after the state.
Tests cover both.
[^1]: 740b09c363/src/ConEmuCD/ConAnsiImpl.cpp (L2264)
To implement this I extended the existing regex variable in the `src/config` dir. In a few test cases, extra space is added intentionally to verify we don't include space in the URL as it looks & feels odd.
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.
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.
A simple change to make it so that, in the GTK4 paste confirmation
dialog, the user can just hit enter/space to confirm the paste.
After some playing around, it seems as though GTK4 needs you to set the
focus on a widget after the entire view has been configured, meaning
that we have to create more references to pass the `confirm_button`
GtkWidget up and up. Not 100% certain if this is the best way to do so,
but:
1. Add the `ButtonsView` to the `PrimaryView` struct (as
`PrimaryView.buttons`)
2. Add the `confirm_button` to the `ButtonsView` struct (as
`ButtonsView.confirm_button`)
3. Call `c.gtk_widget_grab_focus` on (the now-accessible)
`view.buttons.confirm_button`
This seems to work as expected, but I'm not sure if:
1. We should also make `cancel_button` available?
2. There's a better way to expose `confirm_button` to `PrimaryView`?
3. I did a good Zig?
I've never written (or read) Zig code before today so I hope this makes
sense. Feedback welcome!
Basically integrates `ghostty +validate-config` with vim's compiler
feature. This allows validating the config from vim and navigating to
errors e.g. with the quickfix list.
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.
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).
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
