The `Command.zig` tests reach outside the local source tree and look for
files on the host os machine. This introduces some portability issues
for the tests.
The nix build sandbox doesn't include `/usr/bin/env` making it error out
when `zig build test` runs `Command.zig` tests as part of a `nix build`.
Current ci and local development relies on `nix develop` sharing a host os
file system that includes `/usr/bin/env`.
Turns out `/tmp` and `/bin/sh` are available in the build sandbox in
nix so we swap these in to enable nixpkg builds to include testing
ghostty as part of any update cycle.
Duplicating a test process via fork does unexepected things.
zig build test will hang
A test binary created via -Demit-test-exe will run 2 copies of the test suite
This gives people finer-grained control over the coloring of their
window titlebars. Currently only implemented for GTK.
Signed-off-by: Tristan Partin <tristan@partin.io>
Fixes#3648
The confirm-close-surface configuration can now be set to always
ensuring a confirmation dialog is shown before closing a surface, even
if shell integration indicates no running processes.
Based on both context and observed behavior, "now" was intended to be "not" in the paragraph describing the behavior of `focus-follows-mouse` is set to `true`.
Fixes#3528
**Note:**
Not sure if this is what OP requested regarding displaying user defined
shortcuts as hints, but we currently relabel all tabs, but only consider
labels for tabs from 1 to 9. Applying this simple patch should allow for
displaying shortcut hints for tabs beyond 9
<details><summary>Patch</summary>
```diff
diff --git a/macos/Sources/Features/Terminal/TerminalController.swift b/macos/Sources/Features/Terminal/TerminalController.swift
index 7fd1802d..242e5711 100644
--- a/macos/Sources/Features/Terminal/TerminalController.swift
+++ b/macos/Sources/Features/Terminal/TerminalController.swift
@@ -155,13 +155,6 @@ class TerminalController: BaseTerminalController {
tabListenForFrame = windows.count > 1
for (tab, window) in zip(1..., windows) {
- // We need to clear any windows beyond this because they have had
- // a keyEquivalent set previously.
- guard tab <= 9 else {
- window.keyEquivalent = ""
- continue
- }
-
let action = "goto_tab:\(tab)"
if let equiv = ghostty.config.keyEquivalent(for: action) {
window.keyEquivalent = "\(equiv)"
```
</details>
This looks better than the regular dark color. It also happens to match
what Ptyxis does. It does not support non-libadwaita builds.
Signed-off-by: Tristan Partin <tristan@partin.io>
## Description:
Fix `DESTDIR` handling when installing terminfo database files by using
`install_path` instead of `install_prefix`. This ensures files are
correctly installed under `$DESTDIR/$prefix` during packaging.
## Changes:
- Replace `b.install_prefix` with `b.install_path` for terminfo database
installation paths
- This change properly respects the `DESTDIR` environment variable
during installation
## Testing:
I've verified this fix by:
1. Setting `DESTDIR=/tmp/ghostty`
2. Building with:
```bash
DESTDIR=/tmp/ghostty \
zig build \
--prefix /usr \
--system /tmp/offline-cache/p \
-Doptimize=ReleaseFast \
-Dcpu=baseline
```
3. Confirming files are correctly installed to:
```
/tmp/ghostty/usr/share/terminfo/ghostty.terminfo
/tmp/ghostty/usr/share/terminfo/ghostty.termcap
```
The files are now properly installed under `$DESTDIR/$prefix` path
structure as expected.
cc @BratishkaErik - Since you suggested this fix in #3152, would you
mind reviewing this implementation?
Fixes#3152
This was originally fixed in ghostty-org/website#152, but was
accidentally reverted in
[ghostty-org/website#99795d7882a5ee47437454c7c106c2874e0406dc](99795d7882).
P.S., you might want an PR template to discourage folks from making
unsolicited PRs like this :)
P.P.S., you can write issue templates as yaml files to stop folks from
ignoring them (required fields)
I was originally looking into this issue:
https://github.com/ghostty-org/ghostty/issues/3109
When running the logic and triggering a config reload, Xcode warns us
about updating publishable properties from within the notification
callback functions:
<img width="924" alt="Screenshot 2024-12-26 at 5 46 19 PM"
src="https://github.com/user-attachments/assets/38000a09-ffad-4dda-9e2d-a37e5283ff89"
/>
I believe this is because `SurfaceView` is being used as both a bridged
NSView (inside `Surface`) and also an `ObservableObject`, so it's
possible for the notification callback to happen while a SwiftUI render
loop is occurring. The notification delivery happens on whatever thread
posted the message. The better solution long-term is likely to separate
the `ObservableObject` logic into its own class to avoid mixing with the
View logic.
The solution here is to simply move the publishable mutation out of the
current loop via `DispatchQueue.main.async`. I confirmed the warning
goes away with this, and I didn't notice any odd behavior while
reloading config changes.
