Skip to content

Settable ttimeoutlen for Escape key sequences#1679

Open
rolandwalker wants to merge 1 commit intomainfrom
RW/ttimeoutlen-for-escape-key-sequences
Open

Settable ttimeoutlen for Escape key sequences#1679
rolandwalker wants to merge 1 commit intomainfrom
RW/ttimeoutlen-for-escape-key-sequences

Conversation

@rolandwalker
Copy link
Contributor

Description

Since olden times, most terminals have sent Alt+key combinations, function keys, and so on as sequences of characters starting with Escape.

This creates an ambiguity. What if the user simply typed "Escape"? Terminal applications solve this by waiting some period of time before registering a plain "Escape". prompt_toolkit waits a default of 0.5 seconds.

This pause can be a nuisance for users who use the Escape key, especially users of vi keybindings.

Here we provide access to prompt_toolkit's ttimeoutlen property, making the value independent between Emacs and vi modes. At smaller values, an Escape key alone is recognized much more quickly. The toolbar UI for vi modes may still lag on the display of a change in state, but the keystroke is recognized for the typist.

This could also be used to improve the case of pressing Escape to cancel completions.

The setting is named after the Vim setting for familiarity to the group most likely to need it.

Checklist

  • I added this contribution to the changelog.md file.
  • I added my name to the AUTHORS file (or it's already there).
  • To lint and format the code, I ran
    uv run ruff check && uv run ruff format && uv run mypy --install-types .

@rolandwalker rolandwalker self-assigned this Mar 6, 2026
@github-actions
Copy link

github-actions bot commented Mar 6, 2026

Findings

  1. Behavior regression: alternate F4 path does not apply the new timeout setting

    • In the normal F4 handler, toggling key mode updates event.app.ttimeoutlen, but the alternate sequence handler (Esc [ S) only flips editing_mode/key_bindings and leaves ttimeoutlen unchanged.
    • This makes behavior terminal-dependent and breaks the PR’s goal when F4 is emitted as an escape sequence.
    • Fix: mirror the ttimeoutlen assignment in the Esc [ S handler.
    • Reference: mycli/key_bindings.py:112, mycli/key_bindings.py:99
  2. Missing regression test coverage for timeout switching

    • I don’t see tests validating that toggling Emacs/vi updates ttimeoutlen in both keybinding paths (F4 and Esc [ S), or that startup initializes mode-specific timeout.
    • Add tests around keybinding toggle behavior to prevent this regression from recurring.
    • Reference: mycli/key_bindings.py:99, mycli/main.py:1316

No direct security issues found in this diff.

Since olden times, most terminals have sent Alt+key combinations,
function keys, and so on as sequences of characters starting with
Escape.

This creates an ambiguity.  What if the user simply typed "Escape"?
Terminal applications solve this by waiting some period of time before
registering a plain "Escape".  prompt_toolkit waits a default of 0.5
seconds.

This pause can be a nuisance for users who use the Escape key,
especially users of vi keybindings.

Here we provide access to prompt_toolkit's ttimeoutlen property,
making the value independent between Emacs and vi modes.  At smaller
values, an Escape key alone is recognized much more quickly.  The
toolbar UI for vi modes may lag on the display of a change in state, but
the keystroke is recognized for the typist.

The setting is named after the Vim setting for familiarity to the
group most likely to need it.
@rolandwalker rolandwalker force-pushed the RW/ttimeoutlen-for-escape-key-sequences branch from abd1846 to bdd35d8 Compare March 6, 2026 10:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants