A few people were copying that snippet and were facing issues such as
"permission denied", and (after a subsequent `chmod`) "syntax error".
-----
From the [CONTRIBUTING.md]:
> Pull requests should be associated with a previously accepted issue.
I decided to ignore this for a single-word change, since creating a
discussion then waiting for it to be promoted to an issue seemed
pointless for such a minor change.
[CONTRIBUTING.md]:
https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md#pull-requests-implement-an-issue
Based on both context and interaction with ghostty, "now" was intended
to be "not" in the paragraph describing the behavior of
`focus-follows-mouse` is set to `true`.
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.
An exception is raised from the elvish integration module when
`TERMINFO` is set:
```
Exception: exec: "type": executable file not found in $PATH
ghostty-integration.elv:120:60-71: if (and (not $no-sudo) (not-eq "" $E:TERMINFO) (eq file (type -t sudo))) {
ghostty-integration.elv:38:1-123:1:
```
`type` is a builtin in bash and [in
fish](https://fishshell.com/docs/current/cmds/type.html) but it does not
exist in elvish. I suspect it is here as an accidental copy/paste from
the ghostty [fish
integration](https://github.com/ghostty-org/ghostty/blob/main/src/shell-integration/fish/vendor_conf.d/ghostty-shell-integration.fish#L71).
Maybe we can use the elvish
[`has-external`](https://elv.sh/ref/builtin.html#has-external) function
instead (or we could remove that check altogether).
Edit: I think this is in a merge-able state (and it would fix that
error!), but I have just converted this PR to a draft since I can see
other problems with the script. I'll give it a more thorough treatment
later and amend this PR (or also happy to merge this and do other fixes
in separate PRs).
macOS will create `.DS_Store` files in any directory it opens in Finder.
The `+list_themes` command would then list this file as a theme, and
attempt to preview it. `.DS_Store` is a binary file, and is silently
failing in the theme preview...I am on Linux and when I put a small
binary file in my user themes directory, I get a segfault. There is
something about the specific contents in `.DS_Store` that does not cause
this segfault, but lets us silently fail. We should investigate this
further - the issue is in `Config.loadFile` I believe.
In either case, we need to ignore `.DS_Store` so that it is not listed
as a theme.
From the 'CONTRIBUTING.md':
"Pull requests should be associated with a previously accepted issue. If
you open a pull request for something that wasn't previously discussed,
it may be closed or remain stale for an indefinite period of time. I'm
not saying it will never be accepted, but the odds are stacked against
you."
I understand this, and I make a PR without an issue because I feel like
this is actually binary.
On discord I've been informed the quick terminal is macOS only, and in
the documentation I don't think this is expressed, please correct me if
wrong and close this.
If it's correct and the documentation should contain it, then here's my
PR adding that information on the bottom of the section.
If the location of the added information does not fit the style
guidelines I can change it.
We do not currently support bitmap fonts in a real capacity, and they
often are missing some tables which we currently rely on for metrics,
and we don't handle the metrics calculations failing gracefully right
now.
This needs to be fixed for the fontconfig discovery mechanism as well,
so this does NOT close issue #2168 (it fixes the problem on macOS but
not linux).
This greatly alleviates the effect of #2991 since most cases I've seen
that be a problem have been the accidental loading of a bitmap font; but
the underlying issue still exists.
We do not currently support bitmap fonts in a real capacity, and they
often are missing some tables which we currently rely on for metrics,
and we don't handle the metrics calculations failing gracefully right
now.
