Rather than immediately converting a color palette index into an RGB
value for a cell color, when a palette color is used track the palette
color directly in the cell state and convert to an RGB value in the
renderer.
This causes palette color changes to take effect immediately instead of
only for newly drawn cells.
Fixes#1198
This adds a fix similar to what we discovered with termio messages: we
attempt to send a surface message but if the queue is full we unlock the
terminal state and try again waiting forever.
In all cases, its safe to unlock the mutex while sending the message, no
scenario we send a surface message requires this lock to be held.
This fixes an issue in that when running under X11, when a modifier key
is pressed, the modifier state will "lag" behind what should be current.
This is due to how X11 sends modifiers in events, i.e. it sends the
state from right before the key press, and does not include the effects
of the key press itself.
This is corrected by checking the X event queue directly for a pending
XkbStateNotify event (we mask this on modifiers), and setting the
modifiers off of that if we find one. If not, we fall back to the GDK
call.
Fixes#1183
I'm not sure why the original logic was there. When I translated the
original test cases to shell and ran them in xterm, they did NOT match
what Ghostty expected. This updates the tests to match xterm and removes
this case. We can add back in more tests if/when we figure out under
what scenario this original logic was correct (if it ever was).
PR #1168 introduced a loop to kill all children. The `waitpid` call is
issued with the NOHANG flag, which means it returns immediately if no
child has exited. This has the effect that we can repeatedly run through
this loop making this syscall, flooding the system with calls and not
getting timely responses. On my system, this caused Ghostty to take ~30
seconds to close. In my attempts to debug, I added logging to the loop
which resolved the issue. To find out why, I added a loop counter and
found the loop would run > 70 million cycles while trying to close. By
adding logging, I introduced just enough delay in the loop cycle to
prevent whatever flooding of syscalls was happening. This reduced the
loop counter to ~2 cycles before closing.
Add a small delay to prevent syscall flooding.
Fixes#497
This commit resolves two bugs:
First, if a surface is created and destroyed too quickly, the child
process may not have called `setsid` yet (to set the process group). In
this case, `getpgid` returns Ghostty's process group and we were killing
ourselves. We now detect we're about to kill ourselves and wait for our
child to be ready to be killed.
Second, if the child calls setsid but is in the process of execve when
we send a killpg, then the child will be killed but any newly spawned
grandchildren will remain alive. To fix this, we moved the waitpid call
into a kill loop so we can repeatedly kill our child if we detect any
grandchildren are still alive.
Fixes#1159
The cursor position is an "active" coordinate (defined at the top of
Screen.zig), but our resize was treating it as a "viewport" coordinate.
This adds a new configuration `grapheme-width-method` to change the
default behavior that Ghostty uses to calculate grapheme width. The
default value is `unicode` which is identical to setting mode 2027.
**IMPORTANT:** This changes the default Ghostty behavior to be fully
grapheme-aware including ZWJs, VS15, VS16. This may cause issues with
some legacy programs and shells.
I've changed my mind that this should become the default because enough
people use emojis now that I've found in the beta program there are more
issues reported about "incorrect emoji width" than any possibly desync
issues. We'll see.
For legacy programs, this can still be set to `grapheme-width-method =
wcswidth`.
> When the key event is related to an actual modifier key, the corresponding
> modifier's bit must be set to the modifier state including the effect for the
> current event. For example, when pressing the :kbd:`LEFT_CONTROL` key, the
> ``ctrl`` bit must be set and when releasing it, it must be reset. When both
> left and right control keys are pressed and one is released, the release event
> must have the ``ctrl`` bit set. See :iss:`6913` for discussion of this design.
