Fixes#1892
We previously required a negative y or y beyond the height of the window
but in a full screen scenario neither happen, so we add a one pixel
buffer instead where we still scroll.
Thanks to: https://thejh.net/misc/website-terminal-copy-paste
If a paste has the ending sentinel value for a bracketed paste
("\x1b[201~") then the shell may start processing data faster. We now
consider this unsafe even if the `clipboard-paste-bracketed-safe`
setting is true.
Fixes#1724
See background in #1724. The general idea is that for Ghostty
invocations via xdg-terminal-exec, we set the initial title to the
command automatically so that window managers can modify the styling.
We only do this for xdg-terminal-exec because that protocol/spec is
specifically for the scenario that the terminal is being used to launch
a command from the desktop environment.
Fixes#1802
This allows `keybind` configurations to map to any Unicode codepoint. This enables keybindings for which we don't have a registered keycode or for custom keyboard firmwares that may produce arbitrary text (but the Ghostty support is limited to a single codepoint).
The `keybind` syntax is unchanged. If a bound character doesn't map to a known logical key that Ghostty knows about, we map it to a Unicode codepoint. The unicode codepoint is compared against the _unshifted codepoint_ from the apprt key event.
Note that this binding is to a single _codepoint_. We don't support arbitrary sequences of characters or multi-code point graphemes for keybindings due to the complexity in memory management that would introduce.
This also provides a good fallback for scenarios where it might make sense to educate Ghostty about a key code or fix a bug in our keyboard input system, but the unicode data is correct. In that scenario, unicode key binds should allow key binds to still work while we investigate the input issues.
Example:
```
shift+ö=text:hello
```
This now works as expected on a US hardware keyboard with the Hungarian keyboard layout.
Writing scrollback to file is, among other usecases, an interrim solution for searching.
Status quo is to only write history pages, and not the active area. This PR proposes that
the scrollback write includes the active area, which I think is more useful. For example,
you can then do less +G <super+shift+j> if you have long log output and then page and
reverse-search through all of it. It's a bit surprising if the active area is missing.
