[feat]: Preserve standard terminal cursor navigation shortcuts in input fields

[nthomsencph]

Feature Summary

Allow the following keyboard shortcuts in the terminal/task input to preserve default text navigation behavior rather than being intercepted for task switching:

• Cmd/Ctrl + ← / → should move the cursor to the beginning/end of the line.
• Option/Alt + ← / → should move the cursor by word/token.

Currently, these shortcuts are either overridden for task navigation or have no effect, preventing expected text-editing behavior in the prompt/input.

Problem or Use Case

In the current Emdash terminal/task input UI:

• Cmd/Ctrl + Arrow Left/Right navigates between tasks instead of moving the cursor within the current input line.
• Option/Alt + Arrow Left/Right, which in most terminals moves the cursor by tokens/words, does nothing.

This somewhat breaks established terminal and shell editing conventions. Users who rely on familiar text navigation are forced to repeatedly tap basic arrow keys to reposition the cursor, which is inefficient and frustrating—especially for longer prompts or complex input compositions.

For reference: default terminal behavior for these shortcuts is well-established (e.g., beginning/end of line and word jumps). This is also similar to concerns raised in issue #303 about not breaking expected terminal shortcuts. Many interactive shells and terminal emulators rely on the GNU Readline library and POSIX terminal interfaces for line-editing behavior, where standard shortcuts — such as Ctrl+Arrow for word movement and Home/End for line edges — are expected to move the cursor rather than perform other actions.

Proposed Solution

• Retain the default text navigation behavior for these key combinations in all editable text inputs used for prompts/queries:

  • Cmd/Ctrl + Arrow Left/Right → move cursor to beginning/end of line.
  • Option/Alt + Arrow Left/Right → move cursor by token/word.

• Only override these shortcuts when explicitly in a task navigation mode where task switching is requested (e.g., a separate dedicated keybinding context), not within text inputs.

• Ensure that any key event handling logic checks if the current focus is within a text input field before deciding whether to:

  • execute default behavior, or
  • perform custom actions (like task navigation).

• Consider making these text navigation behaviors configurable in settings for advanced users.

Alternatives Considered

No response

Additional Context

No response