feat: keybind hint overlay

[NathanFlurry]

What does this PR do?

Fixes #8730

Added settings:

• keybind_hint.enabled (default true)
• keybind_hint.delay_ms

How did you verify your code works?

Manually tested, both from home screen and from session with different screen sizes.

Screenshots

In-session

Home screen

Tiny screen

Large screen

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• feat(tui): add configurable status line hints #7744 - feat(tui): add configurable status line hints
  • URL: feat(tui): add configurable status line hints #7744
  • This PR also deals with configurable hints functionality in the TUI, which may share similar logic or configuration patterns with the keybind hint settings being added in PR feat: keybind hint overlay #8738.

However, this appears to be a different feature (status line hints vs. keybind hint overlay), so it's related but not a duplicate. The current PR (#8738) is specifically about refining the keybind hint overlay with new settings for keybind_hint.enabled and keybind_hint.delay_ms.

[heymaaz]

Why does h have 2 options??

[NathanFlurry]

Why does h have 2 options??

One is for the home screen, one is for the session. Unfortunately there's no way of knowing if a keybinding is currently being listened for (afaik), so there's no clean way to deduplicate.

If there was a variation on useKeybind to pass in the expected keybind, then there's probably a way to check what mounted components are listening for. That would be a massive refactor, though.

[NathanFlurry]

@iamdavidhill looks like you have something related in the works. Might make sense for this to reuse your keybind table component?

Related thread

[rekram1-node]

Expected: "shift+return"
Received: "shift+↵"

Small test bug looks like

---

I'll send this to David

[iamdavidhill]

i think this is really good, here are my thoughts...

there are three similar features in flux here:

1. command palette which we have - lets you search and enter on a command
2. "whichkey" for leader key experience - very specific to just 'ctrl+x' experience, overlays the content so nothing jumps, i also like the fact that it overlays because it hides the prompt input when in a session which makes it clear the prompt is disabled and the leader key is active
3. "cheatsheet" - all keybinds, not just leader key, pushes the content up so that you can leave it open while you work and learn things, for example you can try out all the prompt input keybinds while the cheatsheet is open

i think there's room for all three in the product. i think they should all follow the same design patterns, which they mostly already do but i think if we took a closer look with this in mind we could polish things up. they should all feel super-related because they're all subsets of the same problem space.

as useful as it is, i'm not sure if the "whichkey" experience should be on by default. i think this is something you should enable. when we have settings in the tui this will be much more discoverable.