Fixes#7131
Regression from #7121
Our consumed mods should not include "alt" if `macos-option-as-alt` is
set. To do this, we need to calculate our consumed mods based on the
actual translation event mods (if available, only available during
keyDown).
This is a large refactor of the keyboard input handling code in
libghostty and macOS. Previously, libghostty did a lot of things that
felt out of scope or was repeated work due to lacking context. For
example, libghostty would do full key translation from key event to
character (including unshifted translation) as well as managing dead key
states and setting the proper preedit text.
This is all information the apprt can and should have on its own.
NSEvent on macOS already provides us with all of this information,
there's no need to redo the work. The reason we did in the first place
is mostly historical: libghostty powered our initial macOS port years
ago when we didn't have an AppKit runtime yet.
This cruft has already practically been the source of numerous issues,
e.g.
https://github.com/ghostty-org/ghostty/issues/5558, but many other hacks
along the way, too.
This commit pushes all preedit (e.g. dead key) handling and key
translation
including unshifted keys up into the caller of libghostty.
Besides code cleanup, a practical benefit of this is that key event
handling on macOS is now about 10x faster on average. That's because
we're avoiding repeated key translations as well as other unnecessary
work. This should have a meaningful impact on input latency but I didn't
measure the full end-to-end latency.
A scarier part of this commit is that key handling is not well tested
since its a GUI component. I suspect we'll have some fallout for certain
keyboard layouts or input methods, but I did my best to run through
everything I could think of.
This also fixes one bug where preedit state didn't properly clear when
changing keyboard layouts. This now does and matches the behavior
of native apps like TextEdit and Terminal.app
This is a large refactor of the keyboard input handling code in
libghostty and macOS. Previously, libghostty did a lot of things that
felt out of scope or was repeated work due to lacking context. For
example, libghostty would do full key translation from key event to
character (including unshifted translation) as well as managing dead key
states and setting the proper preedit text.
This is all information the apprt can and should have on its own.
NSEvent on macOS already provides us with all of this information,
there's no need to redo the work. The reason we did in the first place
is mostly historical: libghostty powered our initial macOS port years
ago when we didn't have an AppKit runtime yet.
This cruft has already practically been the source of numerous issues, e.g.
#5558, but many other hacks along the way, too.
This commit pushes all preedit (e.g. dead key) handling and key translation
including unshifted keys up into the caller of libghostty.
Besides code cleanup, a practical benefit of this is that key event
handling on macOS is now about 10x faster on average. That's because
we're avoiding repeated key translations as well as other unnecessary
work. This should have a meaningful impact on input latency but I didn't
measure the full end-to-end latency.
A scarier part of this commit is that key handling is not well tested
since its a GUI component. I suspect we'll have some fallout for certain
keyboard layouts or input methods, but I did my best to run through
everything I could think of.
Fixes#7099
This adds basic bell features to macOS to conceptually match the GTK
implementation. When a bell is triggered, macOS will do the following:
1. Bounce the dock icon once, if the app isn't already in focus.
2. Add a bell emoji (🔔) to the title of the surface that triggered the
bell. This emoji will be removed after the surface is focused or a
keyboard event if the surface is already focused. This behavior matches
iTerm2.
Note that neither of these respect the `system` `bell-features` config
because they're both unobtrusive (the dock icon bounces only once, the
title change is silent and similar to GTK tab attention) and unrelated
to system settings.
This doesn't add an icon badge because macOS's dockTitle.badgeLabel API
wasn't doing anything for me and I wasn't able to fully figure out
why...
Fixes#7099
This adds basic bell features to macOS to conceptually match the GTK
implementation. When a bell is triggered, macOS will do the following:
1. Bounce the dock icon once, if the app isn't already in focus.
2. Add a bell emoji (🔔) to the title of the surface that triggered
the bell. This emoji will be removed after the surface is focused
or a keyboard event if the surface is already focused. This
behavior matches iTerm2.
This doesn't add an icon badge because macOS's dockTitle.badgeLabel API
wasn't doing anything for me and I wasn't able to fully figure out
why...
Fixes#7066
This fixes an issue where under certain conditions (expanded below), we
would not clear the correct row, leading to the screen having duplicate
data.
This was triggered by a page state of the following:
```
+----------+ = PAGE 0
... : :
4305 |1ABCD00000|
4306 |2EFGH00000|
:^ : = PIN 0
+-------------+ ACTIVE
4307 |3IJKL00000| | 0
+----------+ :
+----------+ : = PAGE 1
0 | | | 1
1 | | | 2
+----------+ :
+-------------+
```
Namely, the cursor had to NOT be on the last row of the first page, but
somewhere on the first page. Then, when an `index` (LF) operation was
performed the result would look like this:
```
+----------+ = PAGE 0
... : :
4305 |1ABCD00000|
4306 |2EFGH00000|
+-------------+ ACTIVE
4307 |3IJKL00000| | 0
:^ : : = PIN 0
+----------+ :
+----------+ : = PAGE 1
0 |3IJKL00000| | 1
1 | | | 2
+----------+ :
+-------------+
```
The `3IJKL` line was duplicated. What was happening here is that we
performed the index operation correctly but failed to clear the cursor
line as expected.
This is because we were always clearing the first row in the page
instead of the row of the cursor.
Test added.
Fixes#7066
This fixes an issue where under certain conditions (expanded below), we
would not clear the correct row, leading to the screen having duplicate
data.
This was triggered by a page state of the following:
```
+----------+ = PAGE 0
... : :
4305 |1ABCD00000|
4306 |2EFGH00000|
:^ : = PIN 0
+-------------+ ACTIVE
4307 |3IJKL00000| | 0
+----------+ :
+----------+ : = PAGE 1
0 | | | 1
1 | | | 2
+----------+ :
+-------------+
```
Namely, the cursor had to NOT be on the last row of the first page,
but somewhere on the first page. Then, when an `index` (LF) operation
was performed the result would look like this:
```
+----------+ = PAGE 0
... : :
4305 |1ABCD00000|
4306 |2EFGH00000|
+-------------+ ACTIVE
4307 |3IJKL00000| | 0
:^ : : = PIN 0
+----------+ :
+----------+ : = PAGE 1
0 |3IJKL00000| | 1
1 | | | 2
+----------+ :
+-------------+
```
The `3IJKL` line was duplicated. What was happening here is that we
performed the index operation correctly but failed to clear the cursor
line as expected.
This is because we were always clearing the first row in the page
instead of the row of the cursor.
Test added.
Supersedes #7075Fixes#7070
This fixes a few separate fullscreen issues with the quick terminal:
1. If we're on a fullscreen space, we can't reliably set the
`autoHideMenuBar` presentation option because macOS itself is managing
it. The fix is to use private APIs to detect we're on a fullscreen space
and avoid this.
2. If our quick terminal is fullscreen when we move spaces, we must exit
and re-enter fullscreen because the frame may change (e.g. due to
menubar changes).
3. If we aren't the frontmost app, we must avoid hiding the menu because
it has no effect and our fullscreen frame would be wrong.
This PR implements a more lightweight alternative to #5326 that contains
features that I personally think Just Make Sense for the bell.
No configs, no GStreamer stuff, just sane defaults to get us started.
This is a bug I noticed in the following scenario:
1. Open Ghostty
2. Fullscreen normal terminal window (native fullscreen)
3. Open quick terminal
4. Move spaces, QT follows
5. Fullscreen the quick terminal
The result was that the menu bar would not disappear since our app is
not frontmost but we set the fullscreen frame such that we expected it.
Fixes#7077
This follows pretty standard behavior across native or popular
applications on both platforms macOS and Linux. The basic behavior is
that if you do a mouse down event and then drag the mouse beyond the
current character, then any mouse up actions are canceled (beyond
emiting the event itself).
This fixes a specific scenario where you could do the following:
1. Click anywhere (mouse down)
2. Drag over a valid link
3. Press command/control (to activate the link)
4. Release the mouse button (mouse up)
5. The link is triggered
Now, step 3 and step 5 do not happen. Links are not even highlighted in
this scenario. This matches iTerm2 on macOS which has a similar
command-to-activate-links behavior.
## Demo
https://github.com/user-attachments/assets/f79767b1-78fd-432b-af46-28194b816747
Fixes#7071
When the mouse is being actively dragged, AppKit continues to emit
mouseDragged events which will update our position appropriately. The
mouseExit event we were sending sends a synthetic (-1, -1) position
which was causing a scroll up.
Fixes#7077
This follows pretty standard behavior across native or popular applications
on both platforms macOS and Linux. The basic behavior is that if you
do a mouse down event and then drag the mouse beyond the current
character, then any mouse up actions are canceled (beyond emiting the
event itself).
This fixes a specific scenario where you could do the following:
1. Click anywhere (mouse down)
2. Drag over a valid link
3. Press command/control (to activate the link)
4. Release the mouse button (mouse up)
5. The link is triggered
Now, step 3 and step 5 do not happen. Links are not even highlighted in
this scenario. This matches iTerm2 on macOS which has a similar
command-to-activate-links behavior.
Fixes#7071
When the mouse is being actively dragged, AppKit continues to emit
mouseDragged events which will update our position appropriately. The
mouseExit event we were sending sends a synthetic (-1, -1) position
which was causing a scroll up.
The helper team has been discussing some common issues we see with
Discussion submissions (missing info, duplicates, etc.), and pluie's
#6937 has been a huge step forward - this PR introduces a template for
the Issue Triage Discussion type.
The template has gone through a few revisions prior to this PR, but I am
certain there are probably a few places to be cleaned up. You can test
it out by [opening a new "Issue Triage" Discussion in my
fork](https://github.com/taylrfnt/ghostty/discussions/new?category=issue-triage).
~~Creating this as a draft for now, since I may not be able to respond
to any review comments in a timely manner.~~
With this PR now it supports the brazilian portuguese language for
ghostty, native speaker and resident, want to bring this language to
this new terminal that is starting to become very fondly to me! Any
questions about it i am free to answer.
