starred/opentui

Fork 0

mirror of https://github.com/anomalyco/opentui.git synced 2026-04-24 20:45:56 +03:00

[GH-ISSUE #551] Option+Backspace (Alt+Delete) key events not detected reliably on macOS (Ghostty) #148

New issue

Closed

opened 2026-03-02 23:44:54 +03:00 by kerem · 4 comments

kerem commented

2026-03-02 23:44:54 +03:00

Owner

Originally created by @LeonMueller-OneAndOnly on GitHub (Jan 19, 2026).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/551

Description:
I am trying to implement "delete word backward" functionality in a component using useKeyboard from @opentui/solid. The standard behavior for this on macOS is Option+Backspace.

I attempted to catch this event using the following logic:

useKeyboard((evt) => {
  const isBackspace = evt.name === "backspace" || evt.name === "delete";
  const isWordDelete = isBackspace && (evt.option || evt.meta);
  
  if (isWordDelete) {
    // Handle delete word
  }
});

Issue:
This condition fails to trigger on Ghostty (macOS), suggesting the key event is not being parsed correctly by @opentui/core.

evt.option or evt.meta may not be set correctly for the Backspace key in this environment.
The raw escape sequence sent by the terminal for Option+Backspace might not be handled in the key parser.

Environment:

OS: macOS
Terminal: Ghostty
Library: @opentui/core / @opentui/solid

Expected Behavior:
Option+Backspace should result in a KeyEvent where name is "backspace" (or "delete") and option (or meta) is true.

Originally created by @LeonMueller-OneAndOnly on GitHub (Jan 19, 2026). Original GitHub issue: https://github.com/anomalyco/opentui/issues/551 **Description:** I am trying to implement "delete word backward" functionality in a component using `useKeyboard` from `@opentui/solid`. The standard behavior for this on macOS is `Option+Backspace`. I attempted to catch this event using the following logic: ```typescript useKeyboard((evt) => { const isBackspace = evt.name === "backspace" || evt.name === "delete"; const isWordDelete = isBackspace && (evt.option || evt.meta); if (isWordDelete) { // Handle delete word } }); ``` **Issue:** This condition fails to trigger on Ghostty (macOS), suggesting the key event is not being parsed correctly by `@opentui/core`. - `evt.option` or `evt.meta` may not be set correctly for the Backspace key in this environment. - The raw escape sequence sent by the terminal for `Option+Backspace` might not be handled in the key parser. **Environment:** - **OS:** macOS - **Terminal:** Ghostty - **Library:** `@opentui/core` / `@opentui/solid` **Expected Behavior:** `Option+Backspace` should result in a `KeyEvent` where `name` is `"backspace"` (or `"delete"`) and `option` (or `meta`) is `true`.

kerem closed this issue

2026-03-02 23:44:54 +03:00

kerem commented

2026-03-02 23:44:55 +03:00

Author

Owner

@msmps commented on GitHub (Jan 19, 2026):

@LeonMueller-OneAndOnly have you tested this with the following config set in ghostty? macos-option-as-alt = true

@msmps commented on GitHub (Jan 19, 2026): @LeonMueller-OneAndOnly have you tested this with the following config set in ghostty? macos-option-as-alt = true

kerem commented

2026-03-02 23:44:55 +03:00

Author

Owner

@LeonMueller-OneAndOnly commented on GitHub (Jan 19, 2026):

This seems to be an issue on Ghossty's side - using other terminal emulators like the VSCode built in one, I do not have this issue.

@LeonMueller-OneAndOnly commented on GitHub (Jan 19, 2026): This seems to be an issue on Ghossty's side - using other terminal emulators like the VSCode built in one, I do **not** have this issue.

kerem commented

2026-03-02 23:44:55 +03:00

Author

Owner

@LeonMueller-OneAndOnly commented on GitHub (Jan 19, 2026):

macos-option-as-alt = true

Thank you very much! This is the issue - sorry for the false issue report here.

Keep on the good work and have a great day!

@LeonMueller-OneAndOnly commented on GitHub (Jan 19, 2026): > macos-option-as-alt = true Thank you very much! This is the issue - sorry for the false issue report here. Keep on the good work and have a great day!

kerem commented

2026-03-02 23:44:55 +03:00

Author

Owner

@LeonMueller-OneAndOnly commented on GitHub (Jan 19, 2026):

The issue when using that config option (macos-option-as-alt = true) in Ghostty + OpenCode is, that now the alt-key can't be used anymore to enter chars like "[" or "{" - at least on German keyboards where we rely on the alt-key for these symbols.

This is not an issue of OpenTUI, but I think we could improve the default behaviour here.

Ghostty handles Option-sequences so that in case they don't produce a printable character, it will be treated as alt. This is a very sensible default in my opinion.

I am currently thinking whether we could replicate this behaviour from Ghostty in OpenTUI.
But I have to admit I am not very familiar with terminal implementations and their behaviour. Therefore, I would like your opinion on this:

Is such a "feature" a sensible idea for this library?
Or would this lead down a route where we would have to maintain extra code for every terminal emulator out there?

For context: here is the excerpt from the documentation of Ghostty:

macOS doesn't have a distinct "alt" key and instead has the "option" key which behaves slightly differently. On macOS by default, the option key plus a character will sometimes produce a Unicode character. For example, on US standard layouts option-b produces "∫". This may be undesirable if you want to use "option" as an "alt" key for keybindings in terminal programs or shells.

This configuration lets you change the behavior so that option is treated as alt.

The default behavior (unset) will depend on your active keyboard layout. If your keyboard layout is one of the keyboard layouts listed below, then the default value is "true". Otherwise, the default value is "false". Keyboard layouts with a default value of "true" are:

    U.S. Standard
    U.S. International

Note that if an Option-sequence doesn't produce a printable character, it will be treated as Alt regardless of this setting. (e.g. alt+ctrl+a).

@LeonMueller-OneAndOnly commented on GitHub (Jan 19, 2026): The issue when using that config option (macos-option-as-alt = true) in Ghostty + OpenCode is, that now the alt-key can't be used anymore to enter chars like "[" or "{" - at least on German keyboards where we rely on the alt-key for these symbols. This is not an issue of OpenTUI, but I think we could improve the default behaviour here. Ghostty handles Option-sequences so that in case they don't produce a printable character, it will be treated as alt. This is a very sensible default in my opinion. I am currently thinking whether we could replicate this behaviour from Ghostty in OpenTUI. But I have to admit I am not very familiar with terminal implementations and their behaviour. Therefore, I would like your opinion on this: Is such a "feature" a sensible idea for this library? Or would this lead down a route where we would have to maintain extra code for every terminal emulator out there? For context: here is the excerpt from the documentation of Ghostty: ``` macOS doesn't have a distinct "alt" key and instead has the "option" key which behaves slightly differently. On macOS by default, the option key plus a character will sometimes produce a Unicode character. For example, on US standard layouts option-b produces "∫". This may be undesirable if you want to use "option" as an "alt" key for keybindings in terminal programs or shells. This configuration lets you change the behavior so that option is treated as alt. The default behavior (unset) will depend on your active keyboard layout. If your keyboard layout is one of the keyboard layouts listed below, then the default value is "true". Otherwise, the default value is "false". Keyboard layouts with a default value of "true" are: U.S. Standard U.S. International Note that if an Option-sequence doesn't produce a printable character, it will be treated as Alt regardless of this setting. (e.g. alt+ctrl+a). ```

kerem referenced this issue

2026-03-02 23:45:58 +03:00

[PR #149] [MERGED] fix: trigger render on raf to run animation request #324

kerem referenced this issue

2026-03-14 08:38:03 +03:00

[GH-ISSUE #148] requestAnimationFrame is broken #803

kerem referenced this issue

2026-03-14 09:18:37 +03:00

[PR #149] [MERGED] fix: trigger render on raf to run animation request #1106