Fixes#5743
This fixes a terrible regression where by fixing one issue we introduced
another, and the other is that ctrl keys didn't work with programs with
Kitty keyboard protocol.
The problem is that our fix blindly assumed control was always consumed
for translation, which is obviously wrong but I didn't think there'd be
downstream effects. The reality is that we need to be more accurate.
This PR makes it so that:
* If macOS provides us with UTF-8 text, we assume all mods were involved
except super
* If macOS does not provide us with UTF-8 text, we use whatever
UCKeyTranslate consumed
* We never allow UCKeyTranslate to consume control because it turns it
into the masked ASCII value and we don't want that.
The only _new_ behavior which fixes the bug is point 2 above.
Tested:
1. Dvorak Ctrl characters
2. Ergo-L Ctrl characters
3. US standard Ctrl characters
4. Japanese IME input Ctrl input to modify IME state
5. Ctrl keybindings with Kitty keyboard protocol in both Kitty and
Neovim
Fixes#5552
This makes the mentioned actions performable. This isn't perfect, but it
does so in a way that resolves the user issue in #5552. This commit
returns an action is NOT performed if it doesn't have splits or tabs
(respectiely for the actions), but also reports its ALWAYS performed if
it does.
This latter logic isn't accurate: we should only return performable if
it was actually done. So for example, goto_split:top should do nothing
if we're already at the top. But, we report it as performed today.
This is good enough to resolve the issue and fix the core problem faced
for 1.1.0.
Fixes#5552
This makes the mentioned actions performable. This isn't perfect, but it
does so in a way that resolves the user issue in #5552. This commit
returns an action is NOT performed if it doesn't have splits or tabs
(respectiely for the actions), but also reports its ALWAYS performed if
it does.
This latter logic isn't accurate: we should only return performable if
it was actually done. So for example, goto_split:top should do nothing
if we're already at the top. But, we report it as performed today.
This is good enough to resolve the issue and fix the core problem faced
for 1.1.0.
Fixes#5448
We previously removed the ctrl modifier for text commit (IME-style) to
workaround a libghostty quirk (as noted in the comment in the diff). But
this broke other keyboard layouts.
This commit attempts to clean this up slightly -- but not completely --
by removing that hack, and only modifying the ctrl behavior for the
UCKeyTranslate call.
Long term, I plan to remove UCKeyTranslate completely, as noted in the
todo comment already written just below this diff.
This fixes the aforementioned issue and hopefully doesn't regress any
other behavior. I tested the following:
1. Dvorak Ctrl characters
2. Ergo-L Ctrl characters
3. US standard Ctrl characters
4. Japanese IME input Ctrl input to modify IME state
Fixes#5448
We previously removed the ctrl modifier for text commit (IME-style)
to workaround a libghostty quirk (as noted in the comment in the diff).
But this broke other keyboard layouts.
This commit attempts to clean this up slightly -- but not completely --
by removing that hack, and only modifying the ctrl behavior for the
UCKeyTranslate call.
Long term, I plan to remove UCKeyTranslate completely, as noted in the
todo comment already written just below this diff.
This fixes the aforementioned issue and hopefully doesn't regress any
other behavior. I tested the following:
1. Dvorak Ctrl characters
2. Ergo-L Ctrl characters
3. US standard Ctrl characters
4. Japanese IME input Ctrl input to modify IME state
* implement `yQuads()` and `draw_octant()`, pretty obvious extensions of
existing code. to allocate up to 3 potential remainder lines, consider
that octants will often appear in a rectangular subset of the terminal.
we want the distributed excess uniformly distributed across such a
region. so:
* one excess row: break symmetry in any direction (pick an arbitrary
tetrad and use it everywhere)
* two excess rows: go to alternating tetrads
* three excess rows: break symmetry, do not use three contiguous tetrads
* our `Octant`s are octary arrays of `bool`, provided as a somewhat
opaque constant table
* the 8-line copy-and-paste draw based on the `Octant` is not the
prettiest thing in the known universe
* we could generalize `draw_sextant()` and `draw_octant()` like
notcurses did, almost certainly
* oh bird thou never wert
with that said, i don't think `draw_octant()` is actually being called
lol, so let's not merge this yet. happy to hear early feedback, though.
Adds buildtime and comptime checks to make sure that Blueprints/UI files
are availble and correctly formed. Will also compile Blueprints to UI
files so that they are available to GTK code.
Fixes#5718
When a terminal is resized with text reflow (i.e. soft-wrapped text),
the cursor is generally reflowed with it.
For example, imagine a terminal window 5-columns wide and you type the
following without pressing enter. The cursor is on the X.
```
OOOOO
OOX
```
If you resize the window now to 8 or more columns, this happens, as
expected:
```
OOOOOOOX
```
As expected, the cursor remains on the "X". This behaves like any other
text input...
Terminals also provide an escape sequence to
[save the cursor (ESC 7 aka
DECSC)](https://ghostty.org/docs/vt/esc/decsc). This includes, amongst
other things, the cursor position. The cursor can be restored with
[DECRC](https://ghostty.org/docs/vt/esc/decrc).
The behavior of the position of the _saved cursor_ in the context of
text reflow is unspecified and varies wildly between terminals Ghostty
does this right now (as do many other terminals):
```
OOOOOOOO
X
```
This commit changes the behavior so that we reflow the saved cursor.
Adds buildtime and comptime checks to make sure that Blueprints/UI files
are availble and correctly formed. Will also compile Blueprints to UI
files so that they are available to GTK code.
Fixes#5718
When a terminal is resized with text reflow (i.e. soft-wrapped text), the cursor
is generally reflowed with it.
For example, imagine a terminal window 5-columns wide and you type the
following without pressing enter. The cursor is on the X.
```
OOOOO
OOX
```
If you resize the window now to 8 or more columns, this happens, as expected:
```
OOOOOOOX
```
As expected, the cursor remains on the "X". This behaves like any other text
input...
Terminals also provide an escape sequence to
[save the cursor (ESC 7 aka DECSC)](https://ghostty.org/docs/vt/esc/decsc).
This includes, amongst other things, the cursor position. The cursor can be
restored with [DECRC](https://ghostty.org/docs/vt/esc/decrc).
The behavior of the position of the _saved cursor_ in the context of text
reflow is unspecified and varies wildly between terminals Ghostty does this
right now (as do many other terminals):
```
OOOOOOOO
X
```
This commit changes the behavior so that we reflow the saved cursor.
As pointed out by @tristan957 the standard path for including the
Adwaita header file is simply "adwaita.h". While it may have been
necessary in the past to use a non-standard include path, that no longer
appears to be the case.
As pointed out by @tristan957 the standard path for including the
Adwaita header file is simply "adwaita.h". While it may have been
necessary in the past to use a non-standard include path, that no longer
appears to be the case.
Caused by #5650
I actually don't understand how this didn't happen before or why we
didn't notice it but it seems like the envmap was never freed. In the
latest debug builds prior to this build GPA reports the leak.
We should free the envmap when the subprocess is deinitialized. But also
we can free the env map as soon as we start the subprocess which saves
some small amount of memory at runtime.
Additionally, we should only be freeing the envmap on error if we
created it.
Caused by #5650
I actually don't understand how this didn't happen before or why we
didn't notice it but it seems like the envmap was never freed. In the
latest debug builds prior to this build GPA reports the leak.
We should free the envmap when the subprocess is deinitialized. But also
we can free the env map as soon as we start the subprocess which saves
some small amount of memory at runtime.
Additionally, we should only be freeing the envmap on error if we
created it.
This should help with API rate limits being hit by macOS builders since
they can't use the Namespace cache that Linux builders can use to cache
Zig dependencies. It will need to be run by Mitchell once so that the
Cachix action can push everything up to the cache and then the full
benefits should be seen. Not sure how using `--system` on all the macOS
builds will affect things overall but it doesn't seem to have affected
the CI.
Partial fixes#5552 (for GTK).
This PR adds the core infrastructure for keybind actions that are
implemented as runtime app actions to be performable. This is done by
having `rt_app.performAction` return a boolean. By default all runtime
app actions return `true` (the action was performed) unless they are
modified to return `true`/`false` as appropriate.
The GTK apprt is modified so that `goto_split`, `previous_tab`,
`next_tab`, `last_tab`, and `goto_tab` are performable. macOS support
will need to be added in a subsequent commit.
This doesn't completely solve the issue for the OP because if the
`goto_split` isn't performable there is no fallback to`previous_tab` or
`next_tab`.
I don't think that the approach taken in #5579 is the right one as it
conflates split and tab navigation unconditionally which I don't think
is what everyone would want. Either a separate action that explicitly
combines the actions or a solution to #3175 will be the ultimate
solution I believe.
This is just a fun change to add a bunch of alternate icons. We don't
want to add too many since this increases the final bundle size but we
also want to have some fun. :)
`WINDOWID` is the conventional environment variable for scripts that
want to know the X11 window ID of the terminal, so that it may call
tools like `xprop` or `xdotool`. We already know the window ID for
window protocol handling, so we might as well throw this in for
convenience.
Originally suggested by #4299
`WINDOWID` is the conventional environment variable for scripts that
want to know the X11 window ID of the terminal, so that it may call
tools like `xprop` or `xdotool`. We already know the window ID for
window protocol handling, so we might as well throw this in for
convenience.
Mitchell Hashimoto