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.
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`.
Installing resources directly under ${prefix}/share causes conflicts
with other packages. This will become more problematic whenever Ghostty
is opened and becomes packaged in distributions.
Instead, install all resources under a "ghostty" subdirectory (i.e.
${prefix}/share/ghostty). This includes themes, shell integration, and
terminfo files.
Only "/usr/share" style paths use the "ghostty" subdirectory. On macOS,
Ghostty is already isolated within its app bundle, and if
$GHOSTTY_RESOURCES_DIR is set then we assume that points to the actual
resources dir (without needing to append "ghostty" to it).
Related to #1102, #1074
Because we are now using the built-in zsh on macOS to launch the real
shell the user wants to use (see #1102 for why), this "outer zsh"
process was consuming our shell integration setup.
This commit adds flags so that this zsh instance doesn't load local
zshrc files and therefore doesn't consume our shell integration setup.
Only SGR, DECSCUSR, DECSTBM, and DECSLRM are handled, as these are the
only ones that Ghostty supports (as far as I can tell) and are the only
ones that seem actually useful.
Implement handling of mode 1047, which enters the alternate screen. This
is not used often, typically applications will favor 1049 (enter alt
screen, save cursor, clear alt screen).
In practice, the primary and selection clipboards are treated exactly
the same, but this allows OSC 52 sequences to use either 's' or 'p' as
the clipboard target.
Fixes#880
If a command is specified but it can't be found, then we try to fallback
to a default command like "sh" and log the issue. This prevents Ghostty
from simply exiting.
Fixes#865
Related to #861
In #861, we fixed a deadlock that could happen if the writer mailbox was
full from the reader thread by waking up the writer thread for
processing.
Unfortunately, the writer thread ALSO handles messages that require the
terminal lock (i.e. resizing, focus state, etc.). If the mailbox
contains these messages, it cannot make forward progress on the writes
(which do not require a lock). This makes it possible still under heavy
write scenarios to fully deadlock the read/write threads.
This commit modifies the behavior so that while we are attempting to
queue a writer message after it fails, we release the lock. This is a
very slow path since we are releasing/acquiring locks under heavy
contention. We can improve it in the future but for now its okay because
this is also a rare situation that only happens under the heaviest loads
that also produce heavy writes.
Normally, we queue all the writes we need from a single `read()` syscall
and only wake up the writer thread at the end of processing that batch
of data.
But under very heavy load or large batches of data, it is possible for the
terminal sequences to generate enough writes to the pty to fill the
writer thread queue while we're still processing the data from `read()`.
This modifies our queuer to attempt to queue, but if the queue is full
we wake up the writer thread immediately then queue again (which should
succeed in every case -- eventually).
PR #850 introduced several color palette OSC setting and querying
sequencing. In doing so, an active palette was introduced to enable
resetting back to the default (configured) palette. The active palette
was not initialized with the configured palette, thus any configured
theme by the terminal was not set at launch.
This behavior can be confirmed thanks to PR #852, which resets the
active palette on configuration reload. To observe the behavior:
1. Set the configured palette to something other than the default
2. Open ghostty. Observe the color palette
3. Reload the configuration
4. Press enter for a new shell prompt. Note the palette has changed
This patch sets the configured palette as the active palette at
initialization.
When the config is changed, update the active palette in addition to the
default palette, but only those colors which have not been changed with
OSC 4.
Default colors are those set by the user in the config file, or an
actual default value if unset. The actual colors are modifiable and can
be changed using the OSC 4, 10, and 11 sequences.
