...unless ~/.config/ghostty/config already exists, then that is opened.
(Or whatever $XDG_CONFIG_HOME points to.)
If both files exists, ghostty reads first the one in ~/.config/ghostty/config
and then the one in Application Support, and merges the settings. In that case,
the menu item opens the file at ~/.config.
Fixes#2890.
This is some last minute flare to get into the 1.0 release. 😄
This introduces some new configurations to let you customize the macOS
app icon at runtime. The runtime icon only applies to certain areas such
as the dock, cmd-tab, etc. It does not change the icon in Finder or on
disk since Apple requires those icons are bundled as files with the
signed app bundle (i.e. you can't change it later without resigning).
I still think this introduces a lot of fun into the macOS app. 😄
I'm still finalizing the exact customization options that will exist for
the icon, so I documented this option as experimental. I'm feeling
pretty good about what's there but I may add other options in the
future.
## Demo
### Beige Yellow
```
macos-icon = custom-style
macos-icon-frame = beige
macos-icon-ghost-color = yellow
macos-icon-screen-color = dark goldenrod,dark khaki
```
### Laker Nation
```
macos-icon = custom-style
macos-icon-ghost-color = yellow
macos-icon-screen-color = purple,maroon
```
Introduce a setting allowing to customize the behavior of the quick terminal
when it loses focus. By default, the quick terminal will automatically hide.
However, you can now configure it to remain open by setting
`quick-terminal-autohide: false`.
Resolves#2558
We used a mix of shorthand and octal representations when printing these
control characters. Standardize on the shorter, more readable shorthand
notation because that's what we use in the other shell integration
scripts.
We used a mix of shorthand and octal representations when printing these
control characters. Standardize on the shorter, more readable shorthand
notation because that's what we use in the other shell integration
scripts.
When outside the viewport, other actions such as scrolling might be
happening, and doing an early return when clearing hyperlinks prevents
scrolling upwards.
We reposition the check, and do not early return so we can process
scrolling when it happens.
This fixes#2645, restoring the ability to scroll upwards while
retaining the behavior of hyperlinks when outside the viewport.
(and, yes I still permit my commits to be relicensed to MIT)
## Before
[Screen Recording 2024-12-21 at
01.36.02.webm](https://github.com/user-attachments/assets/bf144455-ff26-4d4e-9eff-c3d632c02c17)
## After
[Screen Recording 2024-12-21 at
01.36.44.webm](https://github.com/user-attachments/assets/308a795f-971d-4807-b4ba-91bd3685c185)
Given https://github.com/ghostty-org/ghostty/discussions/2994 revert
f1728f594a.
Add documentation to help point people towards the discussion and needed
changes to handle `COMP_WORDBREAKS` not including expected characters.
We know macOS and nixos defaults to including `=` so explicit handling
to change behaviour should only be required if it turns out some
systematically used tool brings in a completion function that changes
`COMP_WORDBREAKS` away from the default. (something they should not be
doing)
If necessary I can create a issue to track handling unexpected word
breaks usage. This change improves the current completions.
I agree to re-license my commits to MIT
We've used a zip for the duration of the private beta but macOS users
expect a dmg. This commit changes both of our release workflows to begin
building a dmg instead of a zip.
Without a prefix option, the result of extracting the archive is the
repository being laid out flat
which requires an extra step of making a directory and changing into it.
` tar -xvf "${SOURCE_TAR}" -C "$BUILD_NAME"`, Change into the directory
first, then perform extraction.
Running a plain `tar -xvf ghostty-source.tar.gz` on results in the
following structures
```
.
├── build.zig
├── build.zig.zon
├── com.mitchellh.ghostty.yml
├── conformance
├── CONTRIBUTING.md
├── dist
├── example
├── flake.lock
├── flake.nix
├── ghostty-source.tar.gz
├── images
├── include
├── macos
├── Makefile
├── nix
├── PACKAGING.md
├── pkg
├── README.md
├── README_TESTERS.md
├── shell.nix
├── src
├── test
├── TODO.md
├── typos.toml
└── vendor
```
With a prefix, extracted contents are kept under a top-level directory
```
.
├── ghostty-source
│ ├── build.zig
│ ├── build.zig.zon
│ ├── com.mitchellh.ghostty.yml
│ ├── conformance
│ ├── CONTRIBUTING.md
│ ├── dist
│ ├── example
│ ├── flake.lock
│ ├── flake.nix
│ ├── images
│ ├── include
│ ├── macos
│ ├── Makefile
│ ├── nix
│ ├── PACKAGING.md
│ ├── pkg
│ ├── README.md
│ ├── README_TESTERS.md
│ ├── shell.nix
│ ├── src
│ ├── test
│ ├── TODO.md
│ ├── typos.toml
│ └── vendor
└── ghostty-source.tar.gz
```
This would be a breaking change for scripts depending on the current
archive format but it I think is easier to work with and a change that
should be made before 1.0.
Ghostty now has a release channel build configuration. Current valid
values are "tip" and "stable" but I imagine more will be added in the
future.
The release channel is inferred whether the version we specify with the
`-Dversion-string` build flag has a prerelease tag or not. If it does,
the release channel is "tip". If it doesn't, the release channel is
"stable".
This also adds a configuration to specify the release channel for
auto-updates for the macOS application.
Ghostty now has a release channel build configuration. Current valid
values are "tip" and "stable" but I imagine more will be added in the
future.
The release channel is inferred whether the version we specify with the
`-Dversion-string` build flag has a prerelease tag or not. If it does,
the release channel is "tip". If it doesn't, the release channel is
"stable".
This also adds a configuration to specify the release channel for
auto-updates for the macOS application.
This adds a new workflow for building and releasing _tagged versions_ of
Ghostty. The workflow is triggered automatically by new tags in the
format of `vX.Y.Z` but can also be manually triggered by running the
workflow from the GitHub Actions UI.
Release artifacts are uploaded to a completely separate R2 bucket with
its own access policy, retention, API keys, and so on.
There is currently no way to switch between "channels" in the macOS app.
I will follow up with a separate commit to add this feature.
This adds a new workflow for building and releasing _tagged versions_
of Ghostty. The workflow is triggered automatically by new tags in the
format of `vX.Y.Z` but can also be manually triggered by running the
workflow from the GitHub Actions UI.
Release artifacts are uploaded to a completely separate R2 bucket
with its own access policy, retention, API keys, and so on.
There is currently no way to switch between "channels" in the macOS
app. I will follow up with a separate commit to add this feature.
When outside the viewport, other actions such as scrolling might be happening, and doing an early return when clearing hyperlinks prevents scrolling upwards.
We do not early return so we can process scrolling when it happens.
`std.fs.accessAbsolute` asserts if the user proposed path is absolute,
which we are seemingly passing as-is with no validating that it is.
When running with safety checks on, passing non-absolute path to
--working-directory will make ghostty crash.
I changed it to use `Dir.access`, which is just `accessAbsolute` without
the check.
This has the side effect of also allowing relative working directory.
The [fixterms](http://www.leonerd.org.uk/hacks/fixterms/) "Really
Special Keypresses" section suggests using CSI 1 ; Ps R for F3, but this
is also a valid cursor position report. The intention was to make
back-compatible changes, so this is fairly considered a specification
bug.
This changes F3 in legacy mode to send CSI 13 ; Ps ~ instead, this is a
variant listed in fixterms, is what kitty protocol uses, and lacks the
problematic overlap with cursor positions.
The KeyEncoder.zig unit test has been changed accordingly, and all tests
pass on my machine.
`std.fs.accessAbsolute` asserts if the user proposed path is absolute,
which we are seemingly passing as-is with no validating that it is.
When running with safety checks on, passing non-absolute path to
--working-directory will make ghostty crash.
I changed it to use `Dir.access`, which is just `accessAbsolute` without
the check.
This has the side effect of also allowing relative working directory.
The [fixterms](http://www.leonerd.org.uk/hacks/fixterms/) "Really
Special Keypresses" section suggests using CSI 1 ; Ps R for F3, but this
is also a valid cursor position report. The intention was to make back-
compatible changes, so this is fairly considered a specification bug.
This changes F3 in legacy mode to send CSI 13 ; Ps ~ instead, this is a
variant listed in fixterms, is what kitty protocol uses, and lacks the
problematic overlap with cursor positions.
The KeyEncoder.zig unit test has been changed accordingly, and all tests
pass on my machine.
The comment in `function_keys.zig` was missing the `>` character for the
sequence. I've confirmed that this was just the comment, Ghostty treats
the original as an SGR sequence, which it is. Conversely, it does treat
`\x1b[>4;2m` as activating modifyOtherKeys.
