Applying the feedback given by @pluiedev to use an enum to specify the
type of quick terminal size configuration given (pixels or percentage).
Updated the Swift code to work with the enum as well.
Added C bindings for the already existing quick-terminal-size
configuration. Created a new QuickTerminalSize struct to hold these
values in Swift. Updated the QuickTerminal implementation to use the
user's configuration if supplied. Retains defaults. Also adds support to
customize the width of the quick terminal (height if quick terminal is
set to right or left).
This adds a new configuration option that controls whether folders
dropped onto the Ghostty dock icon open in a new tab (default) or
a new window.
The option accepts two values:
- tab: Opens folders in a new tab in the main window (default)
- window: Opens folders in a new window
This is useful for users who prefer window-based workflows over
tab-based workflows when opening folders via drag and drop.
This MR addresses #4404 following the approach suggested
[here](https://github.com/ghostty-org/ghostty/issues/4404#issuecomment-2708410143).
Implementing the behavior known e.g. from Putty or Windows Terminal.
The following configuration values for `right-click-action` are
provided:
* `context-menu` - Show the context menu.
* `paste` - Paste the contents of the clipboard.
* `copy` - Copy the selected text to the clipboard.
* `copy-and-paste` - Copy the selected text to the clipboard, paste if
nothing is selected.
* `ignore` - Do nothing, ignore the right-click.
I followed #5935 for getting an idea on where to start. I hope this to
be a temporary solution until "bindable mouse bindings" are introduced.
This is my first time writing Zig code, so I am happy to incorporate any
feedback.
Thank you all very much for your work!
In our webgen we treat 4 consecutive spaces as a code block, which is
often triggered by mistake when a paragraph is encased within a list.
We should probably fix this more thoroughly at some point since I don't
think actual Markdown parsers have the same behavior, but for now we
just fall back to using 3-space indents.
This PR adds a "tabs" title bar style similar to the macOS title bar
style. When `gtk-titlebar-style=tabs` the title bar and the tab bar
will be merged together.
The config entry for controlling this is kept separate from macOS as
macOS has more styles defined that don't map to a GTK title bar style
and it's likely that users that use both macOS and GTK would want
different settings for each platform.
Addresses #4156 and #5892, specifically by implementing @mitchellh's
[request](https://github.com/ghostty-org/ghostty/discussions/5892#discussioncomment-12283628)
for "opt-in shell integration".
## Problem
Ghostty's custom `xterm-ghostty` TERM value breaks terminal
functionality when SSHing to remote systems that lack the corresponding
terminfo entry. This affects enterprise environments, legacy servers,
and ephemeral instances.
## Solution
Adds two independent SSH integration flags within the existing
`shell-integration-features` configuration:
```
shell-integration-features = ssh-env,ssh-terminfo
```
- **`ssh-env`**: TERM compatibility fix (xterm-ghostty → xterm-256color)
+ environment variable propagation (COLORTERM, TERM_PROGRAM,
TERM_PROGRAM_VERSION)
- **`ssh-terminfo`**: Automatic terminfo installation on remote hosts
with caching and utility commands
Flags work independently and harmoniously when combined, allowing users
granular control over SSH integration behavior.
## Implementation
Adds SSH wrapper functions across bash, zsh, fish, and elvish that
handle TERM compatibility, environment propagation, and terminfo
installation. Follows the same pattern as existing shell integration
features - client-side only with graceful fallback behavior.
The flag-based approach allows users to choose exactly the features they
need:
- Environment compatibility only: `ssh-env`
- Terminfo installation only: `ssh-terminfo`
- Optimal experience: `ssh-env,ssh-terminfo`
- No SSH integration: omit both flags
## Evolution Note
Based on maintainer feedback, this evolved from a progressive
enhancement approach (`ssh-integration = basic | full`) to independent
flags within `shell-integration-features`. See discussion below for the
complete architectural evolution and rationale.
Continuation of discussion in
https://github.com/ghostty-org/ghostty/discussions/3134
This changes the behaviour of the new bold-color option to only affect
the default foreground text when set to a static colour. By using a
static colour, the remaining colours are rendered as bright.
For each config entry, add a comment specifying in which release it was
first added. In some cases I note when certain aspects of each config
entry were modified.
Fixes#5256
This updates the macOS apprt to implement the `OPEN_URL` apprt action to
use the NSWorkspace APIs instead of the `open` command line utility.
As part of this, we removed the `ghostty_config_open` libghostty API and
instead introduced a new `ghostty_config_open_path` API that returns the
path to open, and then we use the `NSWorkspace` APIs to open it (same
function as the `OPEN_URL` action).
The behavior of this flag was the opposite of its description in the
docs- luckily, at the same time, the default (true) was the opposite
from what the default actually is in freetype, so users who haven't
explicitly set this flag won't see a behavior difference from this.
This is a big'un.
- **Glyph constraint logic is now done fully on the CPU** at the
rasterization stage, so it only needs to be done once per glyph instead
of every frame. This also lets us eliminate padding between glyphs on
the atlas because we're doing nearest-neighbor sampling instead of
interpolating-- which ever so slightly increases our packing efficiency.
- **Special constraints for nerd font glyphs** are applied based roughly
on the constraints they use in their patcher. It's a simplification of
what they do, the largest difference being that they scale groups of
glyphs based on a shared bounding box so that they maintain relative
size to one another, but that would require loading all glyphs on the
group and I'd want to do that on font load TBH and at that point I'd
basically be re-implementing the nerd fonts patcher in Zig to patch
fonts at load time which is way beyond the scope I want to have. (Fixes
#7069)
- These constraints allow for **perfectly sized and centered emojis**,
this is very nice.
- **Changed the default embedded fonts** from 4 copies (regular, italic,
bold, bold italic) of a patched (and outdated) JetBrains Mono to a
single JetBrains Mono variable font and a single Nerd Fonts Symbols Only
font. This cuts the weight of those down from 9MB to 3MB!
- **FreeType's `renderGlyph` is significantly reworked**, and the new
code is, IMO, much cleaner- although there are probably some edge case
behavior differences I've introduced.
> [!NOTE]
> One breaking change I definitely introduced is changing the
`monochrome` freetype load flag config from its previous completely
backwards meaning to instead the correct one (I also changed the
default, so this won't affect any user who hasn't touched it, but users
who set the `monochrome` flag will find their fonts quite crispy after
this change because they will have no anti-aliasing anymore)
### Future work
Following this change I want to get to work on automatic font size
matching (a la CSS
[`font-size-adjust`](https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust)).
I set the stage for that quite some time ago so it shouldn't be too much
work and it will be a big benefit for users who regularly use multiple
writing systems and so have multiple fonts for them that aren't
necessarily size-compatible.
This is in preparation to move constraint off the GPU to simplify our
shaders, instead we only need to constrain once at raster time and never
again.
This also significantly reworks the freetype renderGlyph function to be
generally much cleaner and more straightforward.
This commit doesn't actually apply the constraints to anything yet, that
will be in following commits.
This deletes the GLFW apprt from the Ghostty codebase.
The GLFW apprt was the original apprt used by Ghostty (well, before
Ghostty even had the concept of an "apprt" -- it was all just a single
application then). It let me iterate on the core terminal features,
rendering, etc. without bothering about the UI. It was a good way to get
started. But it has long since outlived its usefulness.
We've had a stable GTK apprt for Linux (and Windows via WSL) and a
native macOS app via libghostty for awhile now. The GLFW apprt only
remained within the tree for a few reasons:
1. Primarily, it provided a faster feedback loop on macOS because
building the macOS app historically required us to hop out of the
zig build system and into Xcode, which is slow and cumbersome.
2. It was a convenient way to narrow whether a bug was in the
core Ghostty codebase or in the apprt itself. If a bug was in both
the glfw and macOS app then it was likely in the core.
3. It provided us a way on macOS to test OpenGL.
All of these reasons are no longer valid. Respectively:
1. Our Zig build scripts now execute the `xcodebuild` CLI directly and
can open the resulting app, stream logs, etc. This is the same
experience we have on Linux. (Xcode has always been a dependency of
building on macOS in general, so this is not cumbersome.)
2. We have a healthy group of maintainers, many of which have access
to both macOS and Linux, so we can quickly narrow down bugs
regardless of the apprt.
3. Our OpenGL renderer hasn't been compatible with macOS for some time
now, so this is no longer a useful feature.
At this point, the GLFW apprt is just a burden. It adds complexity
across the board, and some people try to run Ghostty with it in the real
world and get confused when it doesn't work (it's always been lacking in
features and buggy compared to the other apprts).
So, it's time to say goodbye. Its bittersweet because it is a big part
of Ghostty's history, but we've grown up now and it's time to move on.
Thank you, goodbye.
(NOTE: If you are a user of the GLFW apprt, then please fork the project
prior to this commit or start a new project based on it. We've warned
against using it for a very, very long time now.)
- Minor tweak to Config.zig to show the new action.
- Rolled back README.md to remove reference to the now non-existent
'shared' subdir and bash-based cache script.
Fixes#7786
Fixes regression from #7683
This is a band-aid fix. The issue is that performable keybinds don't
show up in the reverse mapping that GUI toolkits use to find their key
equivalents. The full explanation of why is already in Binding.zig.
For macOS, we have a way to validate menu items before they're triggered
so we ideally do want a way to get reverse mappings even with
performable keybinds. But I think this wants to be optional and that's
all a bigger change. For now, this is a simple fix that will work.
