When an empty string is given to OSC7, the pwd is reset to nil (as if
the terminal never received a pwd report to begin with). This is
analogous to how OSC0/2 reset the title to nil when given an empty
string.
This is practically useful for macOS because it allows our proxy icon to
also be reset instead of being stuck on the last known path.
This breaks from any known terminal behavior. As far as I can find, this
is totally unspecified so we're somewhat free to do what we want. I
don't think any terminal programs depend on this behavior, so I think
it's safe to change it.
Fixes#2651
First, our OSC parser didn't allow blank OSC 0 or 2 requests. This
should be allowed and this fixes that with a test.
Second, it seems many terminals (iTerm2, Kitty) treat setting a blank
title as resetting to whatever the default title is rather than
explicitly setting it as blank. If a program wants a title to be blank
they should send a single space. This commit follows this behavior.
The bug: ctrl+shift+enter on macOS 15 shows a context menu and doesn't
encode to the terminal.
This avoids a system-wide keybind that shows a context menu in macOS
15+. In general Ghostty doesn't try to override system-wide keybinds
but this one is particularly annoying and not useful to terminal users.
We've discussed making this logic configurable for all system level
keybinds but for now this is a quick fix specifically for
ctrl+shift+enter.
- break formatting values out into a function so that we can
catch errors and never fail
- eliminate the use of toOwnedSentinelSlice since we are using
an arena to clean up memory
Prior to this change both C and c would copy the path to the theme even though
the help screen claimed that c would copy the theme name.
There is a bug in libvaxis that results in both of these matches matching c:
`key.matches('c', .{})`
`key.matches('c', .{ .shift = true })`
Tested:
Before the change: 'c' copies path and 'C' copies path
After the change: 'c' copies the name and 'C' copies the path
I hit an edge case when using Private Wi-Fi addressing on macOS where
the last section of the randomized mac address starts with a '0'. The
hostname parsing for the shell integration didn't handle this case, so
issue #2512 reappeared.
This fixes that by explicitly handling port numbers < 10.
