macOS: bug (alert sound) when resizing with default key bindings

[pabroux]

Hello,

Since the last update (1.1.0), I've recently discovered that when you want to resize a split down, left or right (not up) with the default key bindings, an alert sound is played. It's kind of annoying. I thought it was an issue on my side but after some tests, it seems not.

I've validated my config file with Ghostty cli (i.e. ghostty +validate-config). Nothing was reported. Someone else also reports some alert sounds with key binding #3711 (comment). I don't know whether it's related.

Here is my version:

Ghostty 1.1.0

Version
  - version: 1.1.0
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

Someone else has this issue?

[taylrfnt]

Ditto. I can reproduce this on tip:

❯ ghostty +version
Ghostty 1.1.1-main+cdd20990

Version
  - version: 1.1.1-main+cdd20990
  - channel: tip
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

Here's a recording for clarity:
https://github.com/user-attachments/assets/96fecd2b-af3f-4e3c-a2bd-82e075c0dd42

[taylrfnt]

The recent posts inspired me to try this again (I've been steering clear of splits for a bit) and on tip (1.13+) this appears to be fixed. Can anyone else confirm? If so I'll try and bisect commits so this can be marked as answered/closed with the commit that fixed it.

Edit: After some more tooling around, I discovered that somehow my BEL capability (console bell) is not working at all. So, it may not be fixed and might be something wrong with my local. Not sure how it happened but I'm investigating that too.

[pabroux]

The recent posts inspired me to try this again (I've been steering clear of splits for a bit) and on tip (1.13+) this appears to be fixed. Can anyone else confirm? If so I'll try and bisect commits so this can be marked as answered/closed with the commit that fixed it.

I've just tried tip through the auto-update-channel Ghostty option. It still doesn't work. By the way, I installed Ghostty through Homebrew. What about you?

[taylrfnt]

Homebrew as well. See my recent edit, it might be an issue with my local test build. I'll try and rebuild later to see if that works!

[taylrfnt]

Ok, after some research, turns out console bell is not implemented right now (#2710). So, my build was fine.

I'm testing on a different machine right now than my last test, and it has a different set of apps installed. My best guess is that this is another application's shortcut that Ghostty is intercepting, so I'll have to grab the running apps/procs and go through all of their shortcuts to confirm.

I'll swap back over to the original machine later today and update.

[pabroux]

Ok, after some research, turns out console bell is not implemented right now (#2710). So, my build was fine.

I'm testing on a different machine right now than my last test, and it has a different set of apps installed. My best guess is that this is another application's shortcut that Ghostty is intercepting, so I'll have to grab the running apps/procs and go through all of their shortcuts to confirm.

I'll swap back over to the original machine later today and update.

Well, I've just done three tests:

• Uninstalling most of my programs and all my dotfiles (I use Nix home-manager), except brew;
• Creating a new user on my Macbook and launching the already installed Ghostty;
• Creating a new user on my Macbook and launching the tip-version Ghostty dmg without extracting it (i.e. not putting it into the application folder).

Nothing works...

Maybe I missed something. @taylrfnt, I hope you'll find something.

[pabroux]

Ok, after some research, turns out console bell is not implemented right now (#2710). So, my build was fine.
I'm testing on a different machine right now than my last test, and it has a different set of apps installed. My best guess is that this is another application's shortcut that Ghostty is intercepting, so I'll have to grab the running apps/procs and go through all of their shortcuts to confirm.
I'll swap back over to the original machine later today and update.

Well, I've just done three tests:

• Uninstalling most of my programs and all my dotfiles (I use Nix home-manager), except brew;
• Creating a new user on my Macbook and launching the already installed Ghostty;
• Creating a new user on my Macbook and launching the tip-version Ghostty dmg without extracting it (i.e. not putting it into the application folder).

Nothing works...

Maybe I missed something. @taylrfnt, I hope you'll find something.

Well, I've done a new test from a brand new MacBook Air M2 with nothing installed. I've installed the Ghostty binary and ... the bug is still there. Thus, it seems to really come from Ghostty.

[taylrfnt]

I never managed to get further on my home machine, it still had the issue. I've since been doing some deep dives, and I think I've found the source of the issue:

First order of business....

I'm testing on a different machine right now than my last test, and it has a different set of apps installed. My best guess is that this is another application's shortcut that Ghostty is intercepting, so I'll have to grab the running apps/procs and go through all of their shortcuts to confirm.

I realized when testing on this machine again today that I had added an extra key to the keybind for resizing on my limited test build (the defaults interfered with some autocmds I have) and forget to go back to the default, so I can confirm this is still an issue using the latest tip release.

Next, the reason why this happens...
I found this Stackoverflow post (and a few other resources below) that seems to explain the issue. I believe the split keybindings are not being registered properly in the keybindings dictionary.

I've finally found a concise means to test that theory via this Apple community post:
https://discussions.apple.com/thread/250304211

I'll run this on my test build shortly to see if it works!

[taylrfnt]

Ok, that change (at least as described) did not resolve the issue, but I am not exactly surprised given it's 5+ years old now. I'm looking to see if there's any recent changes or fixes based on the information in that post that I can find for more modern macOS versions :)

[taylrfnt]

Eureka! Blissfully silent resizing with cmd+ctrl+left || right || down via a few minor modifications to the recommendation I linked above:

Create a ~/Library/KeyBindings/DefaultKeyBinding.dict with the following contents (or append, if you have one already):

{
  "@^\UF701" = "noop";
  "@^\UF702" = "noop";
  "@^\UF703" = "noop";
}

I found this incrediblely helpful guide since most of the Apple documentation for that time is archive/nonexistent.

TL;DR is (for any given entry above):

• @ = cmd
• ^ = ctrl
• \U<char code> = Unicode char for each arrow key:

F701 # NSDownArrowFunctionKey
F702 # NSLeftArrowFunctionKey
F703 # NSRightArrowFunctionKey

[pabroux]

I would say it is a workaround. Other apps don't have that issue (e.g. your browser). It is well handled without the DefaultKeyBinding.dict file. I'm not sure but in the past, I don't remember having that issue. Maybe it's due to a macOS update (i.e. compatibility issue) or simply a bug in Ghostty.