Fixes#139
From the issue:
Looking into this now, I think I figured out the broken logic. When launching
from open, the parent process of Ghostty is launchd which appears to set your
SHELL env var to your configured shell when logging in. That's why a restart
fixes it. However, I believe directory services (the macOS equivalent to
/etc/passwd) is updated in real time.
Ghostty does read directory services but at a lower priority than SHELL.
This logic makes sense for CLI-launched terminals but not desktop-launched.
From a CLI you want the terminal you're launching to probably inherit the shell
from the CLI you launched it from. (Note that using open explicitly forces a
launchd-style launch so it quacks as if it was double-clicked on the desktop).
In conclusion, I believe the correct logic is to invert the priority on SHELL
vs directory services when Ghostty detects it was launched from launchd. We
already have this detection logic in Ghostty because we use it for a number of
other things as well, so this should be easy to fix. I'll work on it later
today.
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.
