Related to #1802
CSIu format sends a unicode codepoint but we were just sending the first
byte of the utf8 sequence, which is very much not right. This fixes that
by parsing the utf-8.
It isn't defined what to do if the utf-8 sequence is invalid or has
multiple codepoints so we just skip CSIu encoding in that case.
Reproduction: HU layout Ctrl+ő
On release, we were previously not sending an alt text (we were sending
it properly on press). Kitty sends it also on release and the spec makes
it clear we should send it on release. This was just due to some faulty
logic; added a test and fixed that.
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.
Some opener commands (like macOS's open) finish immediately after
running, while others (xdg-open) do not, staying alive until the
application that was opened itself terminates.
For now, we explicitly state whether or not we should wait for a
command. Eventually we may want to do something more generic (e.g. wait
for some predetermined amount of time and if the process does not
complete, give up without collecting stderr).
Fixes#1808
When resolving a codepoint, we first attempt to find the default
presentation (if an explicit one is not given), but we were not falling
back to "any" in case that presentation was not found.
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.
Fish automatic integration taken as an example.
Just like fish, Elvish checks `XDG_DATA_DIRS` for its modules.
Thus, Fish integration in zig is reused, and integration in
Elvish now removes `GHOSTTY_FISH_XDG_DIR` environment variable
on launch.
Related to #1768 but doesn't fix it properly.
This is a temporary hack to avoid some issues with fonts that have mixed
color/non-color glyphs. If there are mixed presentations and the font
does not have emoji codepoints, then we assume it is text. This fixes
the typical scenarios.
This is not a long term solution. A proper long term solution is to
detect this scenario and on a per-glyph basis handle colorization (or
the lack thereof) correctly. It looks like to do this we'll have to
parse some font tables which is considerably more work so I wanted to do
this first.
Fixes#1795
This only affected CoreText. When testing with Freetype the
strikethroughs looked correct for fonts with and without leading
metrics.
This commit adjusts our strikethrough position for fonts that have a
leading metric set to better center it. Previously, we centered the
position _including_ the leading value. The leading value is blank, so
we must center it excluding that value.
Fixes#1784
This was just a misunderstanding of the "spec." When both a y offset
into the image is specified and a height, the image should be stretched.
I mistakingly thought that the image should be offset (even with this
misunderstanding there was a data corruption bug).
This resolves the issue and output matches Kitty.
See: https://github.com/ziglang/zig/issues/17851
Users were noticing that frame render times got slower over time. I
believe (thanks to community for pointing it out) that this is the
culprit.
This works around this issue by clearing and reinitializing the LRU
after a certain number of evictions. When the Zig issue has a better
resolution (either rehash() as a workaround or a better hash
implementation overall) we can change this.
- contains `.elv` file that implements the core of Elvish integration.
- does not contain routines needed for automatic integration.
- stored in `./elvish/lib/...` in preparation for automatic integration:
Elvish imports `.../elvish/lib/*.elv`.
checklist:
- no confirmation on close where the cursor is at prompt:
works, only occasionally doesn't, I'm not yet sure when.
- new terminals start in pwd of previously focused terminal: works
- prompts resize correctly: works
- triple-click while holding `ctrl` selects output of a command:
works (when mouse is over the output)
- cursor at the prompt is turned into a bar: works
- ghostty:`jump_to_prompt` scrolls through prompts: works
- `opt`-click moves cursor at the prompt: works
- `sudo` preserves ghostty terminfo:
untested - not sure when this is needed exactly, but did not encounter
any errors after sudo, either
When the -c option is present, then commands are read from the first
non-option argument command string. Our simple implementation assumes
that if we see at least the '-c' option, a command string was given, and
the shell is always considered to be non-interactive - even if the '-i'
(interactive) option is also given.
