[GH-ISSUE #380] bug: shift+space doesn't insert a space on wezterm #862

New issue

Closed

opened 2026-03-14 08:51:01 +03:00 by kerem · 2 comments

kerem commented

2026-03-14 08:51:01 +03:00

Owner

Originally created by @fareesh on GitHub (Dec 4, 2025).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/380

Summary

Input components do not accept shift+space key combinations when using the "wezterm" terminal. The key combination works correctly in other terminals like Ghostty. Often times when in the flow of typing, the shift key can sometimes remain pressed for longer than expected, resulting in a missed space.

Environment

Terminal: wezterm
OS: Linux (and likely others)
Package: @opentui/core

Steps to Reproduce

Run any example with Input components (e.g., Input & Select layout demo)
Focus on an input field
Press shift+space
Observe that no space character is inserted

Expected Behavior

shift+space should insert a space character in the input field, just like regular space.

Actual Behavior

shift+space is ignored and no character is inserted.

Root Cause

wezterm sends the ModifyOtherKeys escape sequence \u001b[27;2;32~ for shift+space, which the Input component's text insertion logic does not handle. The component only checks for single-character sequences, but ModifyOtherKeys sequences are multi-character escape sequences.

Technical Details

wezterm sequence: \u001b[27;2;32~ (ModifyOtherKeys protocol)
Parsed result: { name: "space", sequence: "\u001b[27;2;32~", shift: true }
Issue: Input component checks keySequence.length === 1, which fails for escape sequences
Working terminals: Ghostty sends \u001b[32;2u (Kitty protocol) which works correctly

Possible Fix

Update the Input component's handleKeyPress method to handle ModifyOtherKeys sequences for printable characters, specifically the space character case:

// Handle ModifyOtherKeys sequences (e.g., wezterm shift+space)
else if (typeof key !== "string" && key.name === "space" && !key.ctrl && !key.meta && !key.super && !key.hyper) {
  this.insertText(" ")
  return true
}

but this feels like an ugly hack so idk! I suppose the other workaround would be to just change the wezterm config and handle shift+space differently.

Originally created by @fareesh on GitHub (Dec 4, 2025). Original GitHub issue: https://github.com/anomalyco/opentui/issues/380 ## Summary Input components do not accept shift+space key combinations when using the "wezterm" terminal. The key combination works correctly in other terminals like Ghostty. Often times when in the flow of typing, the shift key can sometimes remain pressed for longer than expected, resulting in a missed space. ## Environment - **Terminal**: wezterm - **OS**: Linux (and likely others) - **Package**: @opentui/core ## Steps to Reproduce 1. Run any example with Input components (e.g., Input & Select layout demo) 2. Focus on an input field 3. Press shift+space 4. Observe that no space character is inserted ## Expected Behavior shift+space should insert a space character in the input field, just like regular space. ## Actual Behavior shift+space is ignored and no character is inserted. ## Root Cause wezterm sends the ModifyOtherKeys escape sequence `\u001b[27;2;32~` for shift+space, which the Input component's text insertion logic does not handle. The component only checks for single-character sequences, but ModifyOtherKeys sequences are multi-character escape sequences. ## Technical Details - **wezterm sequence**: `\u001b[27;2;32~` (ModifyOtherKeys protocol) - **Parsed result**: `{ name: "space", sequence: "\u001b[27;2;32~", shift: true }` - **Issue**: Input component checks `keySequence.length === 1`, which fails for escape sequences - **Working terminals**: Ghostty sends `\u001b[32;2u` (Kitty protocol) which works correctly ## Possible Fix Update the Input component's `handleKeyPress` method to handle ModifyOtherKeys sequences for printable characters, specifically the space character case: ```typescript // Handle ModifyOtherKeys sequences (e.g., wezterm shift+space) else if (typeof key !== "string" && key.name === "space" && !key.ctrl && !key.meta && !key.super && !key.hyper) { this.insertText(" ") return true } ``` but this feels like an ugly hack so idk! I suppose the other workaround would be to just change the wezterm config and handle shift+space differently.

kerem closed this issue

2026-03-14 08:51:06 +03:00

kerem commented

2026-03-14 08:51:11 +03:00

Author

Owner

@kommander commented on GitHub (Dec 5, 2025):

I works in the text area though? The Editor Demo in the examples uses the text area. I want to replace the input component to underneath use the text area, that should fix this. @msmps had something for this.

@kommander commented on GitHub (Dec 5, 2025): I works in the text area though? The Editor Demo in the examples uses the text area. I want to replace the input component to underneath use the text area, that should fix this. @msmps had something for this.

kerem commented

2026-03-14 08:51:17 +03:00

Author

Owner

@fareesh commented on GitHub (Dec 6, 2025):

Seems like the same issue exists with TextareaRenderable. When I run it with the else I added to renderables/Input the Input Demo processes shift+space correctly but the Editor demo has the same problem.

@fareesh commented on GitHub (Dec 6, 2025): Seems like the same issue exists with `TextareaRenderable`. When I run it with the `else` I added to `renderables/Input` the Input Demo processes shift+space correctly but the Editor demo has the same problem.