Fixes#4554
When a process exited on its own (we didn't kill it), we were not
calling waitpid. This commit adds a waitpid call in the event loop
process exit notification.
This happened because when an external exit happened we could call
`subprocess.externalExit` which tells our subprocess manager to NOT kill
the process (since its already dead). Unfortunately in this case it
means we also didn't call waitpid.
Fixes#4554
xev.Process.wait is documented as being equivalent to calling `waitpid`,
i.e. including reaping the process. On Linux, it does this automatically
by using pidfd and the `waitid` syscall. On macOS, it wasn't doing this.
This commit updates libxev to include a fix that explicitly calls
`waitpid` for kqueue.
Fixes#4884
When our command exits, it will close the pty slave fd. This will
trigger a HUP on our poll. Previously, we only checked for IN. When a fd
is closed, IN triggers forever which would leave to an infinite loop and
100% CPU.
Now, detect the HUP and exit the read thread.
Fixes#4884
When our command exits, it will close the pty slave fd. This will
trigger a HUP on our poll. Previously, we only checked for IN. When a fd
is closed, IN triggers forever which would leave to an infinite loop and
100% CPU.
Now, detect the HUP and exit the read thread.
Multiple fixes to prevent file descriptor leaks:
- libxev eventfd now uses CLOEXEC
- linux: cgroup clone now uses CLOEXEC for the cgroup fd
- termio pipe uses pipe2 with CLOEXEC
- pty master always sets CLOEXEC because the child doesn't need it
- termio exec now closes pty slave fd after fork
There still appear to be some fd leaks happening. They seem related to
GTK, they aren't things we're accessig directly. I still want to
investigate them but this at least cleans up the major sources of fd
leakage.
Multiple fixes to prevent file descriptor leaks:
- libxev eventfd now uses CLOEXEC
- linux: cgroup clone now uses CLOEXEC for the cgroup fd
- termio pipe uses pipe2 with CLOEXEC
- pty master always sets CLOEXEC because the child doesn't need it
- termio exec now closes pty slave fd after fork
There still appear to be some fd leaks happening. They seem related to
GTK, they aren't things we're accessig directly. I still want to
investigate them but this at least cleans up the major sources of fd
leakage.
This fixes a regression introduced by the rework of this area before
during the color space changes (#4913). It seems like the original
intent of this code was the behavior it regressed to, but it turns out
to be better like this.
This fixes a regression introduced by the rework of this area before
during the color space changes. It seems like the original intent of
this code was the behavior it regressed to, but it turns out to be
better like this.
## Description
Fixed an issue where hyperlinks would maintain their hover state when
the mouse is outside the viewport while holding the Cmd key. This
created inconsistent behavior with the window's standard hover state
clearing logic.
## Changes
- Added viewport boundary check in `mouseRefreshLinks` function to
prevent link processing when cursor is outside the window
## Testing
To reproduce and verify the fix:
1. Run `fd --hyperlink "\.zig$" src/apprt` to create hyperlinks
2. Move mouse over a hyperlink (it should highlight)
3. Move mouse outside window
4. Hold Cmd key
- Before: Link would show hover state
- After: Link remains in non-hover state
Fixes#5252
@rrotter Could you please try this to see if it solves your issue?
A '-' or '--' argument signals the end of bash's own options. All
remaining arguments are treated as filenames and arguments. We shouldn't
perform any additional argument processing once we see this signal.
We could also assume a non-interactive shell session in this case unless
the '-i' (interactive) shell option has been explicitly specified, but
let's wait on that until we know that doing so would solve a real user
problem (and avoid any false negatives).
Currently, `sudo_has_sudoedit_flags` variable is being erased when `for`
block ends.
Change its scope to `--function` to prevent this.
Fixes `sudo: you may not specify environment variables in edit mode`.
Duplicate existing reference docs generation to cover cli actions. Docs
update pass to make the structure consistent.
See https://github.com/ghostty-org/website/pull/253 for website changes.
Adds a Nix VM configuration to run Gnome/Wayland. The primary purpose
will be testing Ghostty in a "clean" environment. I'm going to continue
to experiment with running this in CI to see if we can do some basic
testing of GTK since it's difficult to unit test that code.
To use, run `nix run .#wayland-gnome` in the Ghostty source directory. I
have no idea if this works on macOS. There's probably a lot of extra
stuff that can be trimmed to slim it down.
Whatever directory you run this from will be mounted at `/tmp/shared` in
the VM. The `ghostty` user runs as uid/gid 1000/1000 so that may affect
your ability to read/write that directory if your host system user runs
as a different uid/gid.
If this is something that we'd like to keep, we should add VM
definitions for KDE Plasma and maybe one tiling window manager.
https://github.com/user-attachments/assets/57190913-f338-4383-93aa-90c9e351543d
Requesting the initial color scheme on systems where the D-Bus interface
is nonexistent would delay Ghostty startup by 1-2 minutes. That's not
acceptable. Our color scheme events are already async-friendly anyway.
Fixes#4632
Requesting the initial color scheme on systems where the D-Bus interface
is nonexistent would delay Ghostty startup by 1-2 minutes. That's not
acceptable. Our color scheme events are already async-friendly anyway.
Fixes#4632
Fixes#4631
This introduces a mechanism by which parsed config fields can be renamed
to maintain backwards compatibility. This already has a use case --
implemented in this commit -- for `background-blur-radius` to be renamed
to `background-blur`.
The remapping is comptime-known which lets us do some comptime
validation. The remap check isn't done unless no fields match which
means for well-formed config files, there's no overhead.
For future improvements:
- We should update our config help generator to note renamed fields.
- We could offer automatic migration of config files be rewriting them.
- We can enrich the value type with more metadata to help with config
gen or other tooling.
Fixes#4631
This introduces a mechanism by which parsed config fields can be renamed
to maintain backwards compatibility. This already has a use case --
implemented in this commit -- for `background-blur-radius` to be renamed
to `background-blur`.
The remapping is comptime-known which lets us do some comptime
validation. The remap check isn't done unless no fields match which
means for well-formed config files, there's no overhead.
For future improvements:
- We should update our config help generator to note renamed fields.
- We could offer automatic migration of config files be rewriting them.
- We can enrich the value type with more metadata to help with
config gen or other tooling.
Currently `macos-titlebar-style = hidden` doesn't prevent the native
window drag gesture in the top region of the window- in the original PR
it did, but there were issues with how it went about it so it was
removed (see c6bbdfb). I figured out how to safely and simply remove the
gesture, and as a bonus it opens up potential future enhancements.
The native window drag region is driven ultimately by the window's
`contentLayoutRect`, so we can just override it in `TerminalWindow` to
return a rect the size of the full window, disabling the gesture without
causing any side effects by altering the responder chain.
This makes `macos-titlebar-style = hidden` a much nicer experience. The
window can still be resized, managed by the OS and third party window
managers, and dragged by the edges, but the native drag gesture in the
titlebar region is fully avoided.
### Future work
We may consider adjusting this to produce a `contentLayoutRect` that
doesn't include the padding area of the terminal grid(s), so that the
window can be dragged from a larger region around the edges (and not
just the resize region).
The native window drag region is driven ultimately by the window's
`contentLayoutRect`, so we can just override it in `TerminalWindow`
to return a rect the size of the full window, disabling the gesture
without causing any side effects by altering the responder chain.
NEEDS REVIEW
continuation of #5037resolves#4729
renders all shaders to the default buffer and then copies it to the
designated custom shader texture.
this is a draft pr because:
- it introduces a new shader "pipeline" which doesnt fit in with how the
system was designed to work (which is only rendering to the fbo)
- im not sure if this is the best way to achieve shaders being able to
sample their output while also drawing to the screen. the cusom fbo
(previous implementation) was useful in that it modularized the custom
shader stage in rendering
---------
Co-authored-by: Mitchell Hashimoto <m@mitchellh.com>
Fixes#3567
ibus 1.5.29 doesn't trigger a preedit end state when text is committed.
This is fixed in ibus 1.5.30, but we need to handle this case for older
versions which are shipped on LTS distributions such as Ubuntu.
Every other input method engine I've tried thus far also triggers a
preedit end state when text is committed, and none would expect preedit
to continue after text is committed. So I think it's safe to assume that
this is the expected behavior.
Fixes#3567
ibus 1.5.29 doesn't trigger a preedit end state when text is committed.
This is fixed in ibus 1.5.30, but we need to handle this case for older
versions which are shipped on LTS distributions such as Ubuntu.
Every other input method engine I've tried thus far also triggers a
preedit end state when text is committed, and none would expect preedit
to continue after text is committed. So I think it's safe to assume that
this is the expected behavior.
A '-' or '--' argument signals the end of bash's own options. All
remaining arguments are treated as filenames and arguments. We shouldn't
perform any additional argument processing once we see this signal.
We could also assume a non-interactive shell session in this case unless
the '-i' (interactive) shell option has been explicitly specified, but
let's wait on that until we know that doing so would solve a real user
problem (and avoid any false negatives).
Related to #3567
This cleans up our handling of when GTK tells us the input method
handled the key press to address more scenarios we should not encode the
key event. The comments in this diff should explain clearly.
Reproduction is simple:
1. Use ibus (X11 or Wayland doesn't matter)
2. Press `super+.` to activate the emoji keyboard
3. Notice the `.` is written to the shell AND the emoji keyboard is
activated.
The bug is that `.` should not be encoded since it was used to activate
the emoji keyboard. This PR fixes that.
This cleans up our handling of when GTK tells us the input method
handled the key press to address more scenarios we should not encode the
key event. The comments in this diff should explain clearly.
Fixes#4332
This commit fundamentally reworks the input method handling in the GTK
apprt, making it work properly (as reported in the linked issue) on both
Wayland and X11. This was tested with both a Gnome desktop on Wayland
and i3 on X11 with fcitx and mozc.
The main changes are:
- Both key press and release events must be forwarded to the input
method.
- Input method callbacks such as preedit and commit must be expected
outside of keypress events to handle on-screen keyboards and
non-keyboard input devices.
- Input methods should always commit when told to. Previously, we would
only commit when a keypress event was given. This is incorrect. For
example, it didn't work with input method changes outside the app which
should result in committed text (as can be seen with "official" Gnome
apps like Notes or Console).
The key input handling also now generally does less so I think input
latency should be positively affected by this change. I didn't measure.
Fixes#4332
This commit fundamentally reworks the input method handling in the GTK
apprt, making it work properly (as reported in the linked issue) on both
Wayland and X11. This was tested with both a Gnome desktop on Wayland
and i3 on X11 with fcitx and mozc.
The main changes are:
- Both key press and release events must be forwarded to the input
method.
- Input method callbacks such as preedit and commit must be expected
outside of keypress events to handle on-screen keyboards and
non-keyboard input devices.
- Input methods should always commit when told to. Previously, we would
only commit when a keypress event was given. This is incorrect. For
example, it didn't work with input method changes outside the app
which should result in committed text (as can be seen with "official"
Gnome apps like Notes or Console).
The key input handling also now generally does less so I think input
latency should be positively affected by this change. I didn't measure.
Resolves#4523
More notably this fixes a memory corruption crash that can occur while
resizing the font under Metal while there's a lot of active changes
occurring (e.g. while running DOOM fire). The change where all
background colors are explicitly written exposed this issue, though it
was technically a problem the whole time I'm fairly sure, just that the
corruption it caused before was benign.
This significantly improves the robustness of the renderers since it
prevents synchronization issues from causing memory corruption due to
out of bounds read/writes while building the cells.
TODO: when viewport is narrower than renderer grid size, fill blank
margin with bg color- currently appears as black, this only affects
DECCOLM right now, and possibly could create single-frame artefacts
during poorly managed resizes, but it's not ideal regardless.
This significantly improves the robustness of the renderers since it
prevents synchronization issues from causing memory corruption due to
out of bounds read/writes while building the cells.
TODO: when viewport is narrower than renderer grid size, fill blank
margin with bg color- currently appears as black, this only affects
DECCOLM right now, and possibly could create single-frame artefacts
during poorly managed resizes, but it's not ideal regardless.
#4033 introduced a `ctrl-shift-w` binding to close a tab, but it doesn't
respect the `confirm-close-surface` option. Now `ctrl-shift-w` will ask
for confirmation exactly the same as clicking the close button with the
mouse.
