end instead of buffer #468

New issue

Closed

opened 2026-03-02 23:46:38 +03:00 by kerem · 0 comments

kerem commented

2026-03-02 23:46:38 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/anomalyco/opentui/pull/344
Author: @remorses
Created: 11/25/2025
Status: ✅ Merged
Merged: 11/26/2025
Merged by: @kommander

Base: main ← Head: fix/ctrl-a-e-line-navigation

📝 Commits (3)

91ace0e fix: Ctrl+A/E navigate to line start/end instead of buffer
90cf4da feat: Home/End keys navigate to buffer start/end with selection support
7d1602d fix: use uppercase key names in Home/End tests

📊 Changes

2 files changed (+120 additions, -14 deletions)

View changed files

📝 packages/core/src/renderables/Textarea.ts (+18 -8)
📝 packages/core/src/renderables/__tests__/Textarea.editing.test.ts (+102 -6)

📄 Description

The default keybindings for Ctrl+A and Ctrl+E in TextareaRenderable were incorrectly mapped to buffer-home and buffer-end (jumping to the start/end of the entire textarea). This PR changes them to line-home and line-end to match standard Emacs/readline behavior used in virtually all Unix shells and TUI applications.

This is the standard behavior:

Ctrl+A → beginning of current line
Ctrl+E → end of current line

This fix also resolves unexpected behavior on macOS terminals. Many terminal emulators (including Ghostty, iTerm2, Terminal.app, and Zed's integrated terminal) translate Cmd+Left and Cmd+Right into Ctrl+A and Ctrl+E respectively. This is because macOS GUI applications use Cmd+Left/Right for line navigation, so terminals map these to the equivalent Unix keybindings. With the previous incorrect mapping, pressing Cmd+Left would unexpectedly jump to the start of the entire textarea instead of just the current line.

Tested on both Ghostty and Zed terminal on macOS.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/anomalyco/opentui/pull/344 **Author:** [@remorses](https://github.com/remorses) **Created:** 11/25/2025 **Status:** ✅ Merged **Merged:** 11/26/2025 **Merged by:** [@kommander](https://github.com/kommander) **Base:** `main` ← **Head:** `fix/ctrl-a-e-line-navigation` --- ### 📝 Commits (3) - [`91ace0e`](https://github.com/anomalyco/opentui/commit/91ace0e6844ed85668b8912594a150b4654b5d18) fix: Ctrl+A/E navigate to line start/end instead of buffer - [`90cf4da`](https://github.com/anomalyco/opentui/commit/90cf4da828aa30dc5d29b055b2c5657871f91db0) feat: Home/End keys navigate to buffer start/end with selection support - [`7d1602d`](https://github.com/anomalyco/opentui/commit/7d1602d76f2573733ce674033f5468c2c26b599b) fix: use uppercase key names in Home/End tests ### 📊 Changes **2 files changed** (+120 additions, -14 deletions) <details> <summary>View changed files</summary> 📝 `packages/core/src/renderables/Textarea.ts` (+18 -8) 📝 `packages/core/src/renderables/__tests__/Textarea.editing.test.ts` (+102 -6) </details> ### 📄 Description The default keybindings for `Ctrl+A` and `Ctrl+E` in `TextareaRenderable` were incorrectly mapped to `buffer-home` and `buffer-end` (jumping to the start/end of the entire textarea). This PR changes them to `line-home` and `line-end` to match standard Emacs/readline behavior used in virtually all Unix shells and TUI applications. This is the standard behavior: - `Ctrl+A` → beginning of current line - `Ctrl+E` → end of current line This fix also resolves unexpected behavior on macOS terminals. Many terminal emulators (including Ghostty, iTerm2, Terminal.app, and Zed's integrated terminal) translate `Cmd+Left` and `Cmd+Right` into `Ctrl+A` and `Ctrl+E` respectively. This is because macOS GUI applications use `Cmd+Left/Right` for line navigation, so terminals map these to the equivalent Unix keybindings. With the previous incorrect mapping, pressing `Cmd+Left` would unexpectedly jump to the start of the entire textarea instead of just the current line. Tested on both Ghostty and Zed terminal on macOS. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>