@Lee-WonJun thanks for resurrecting this! Can you address the comment from the menu box about the overlapping keys?

@jacob314 this one looks good to me. I want to double check with you.

Does my understanding of the Gemini review seem correct?

• Previously, either useInput or useKeypress would run — meaning, if useKeypress was active, the useInput hook would not be triggered. Is that the intended meaning?

I'm not fully familiar with how priority or exclusivity works between them, but if my assumption is correct, it seems that both hooks were already running concurrently even before.

When I test it with the stable version of Gemini or the main branch build (while both components are active), all hooks appear to be invoked. So perhaps I misunderstood the intent, or maybe there's some focus management behavior that I'm not aware of?

(Please note that I may be running into an XY problem due to my limited understanding of Ink or frontend behavior.)

@jacob314 thanks for your feedback and suggestions! I've clarified my thought process below based on your comments.

Reason for Using Lambda Functions

The main reason I've implemented this using lambda functions is that, I'm not aware of the detailed plans for all the shortcuts (or key binding) that gemini-cli will need to support.

Ideal Architecture and Staged Implementation

I'm also a big fan of data-driven DSLs (Domain-Specific Languages), and the ideal architecture I had in mind is as follows:
[String DSL (User Config)] → [ADT-based DSL (Core)] → [Callable Interface]

However, this PR follows a staged approach rather than implementing the entire feature at once. In this first stage (Stage 1), I've focused on consolidating the interfaces related to shortcuts.

I've excluded text-buffer.ts for now as it seems to be a more low-level component, which I'll explain further below.

Thoughts on DSL Design

Users will need to be able to override shortcuts via settings.json. Therefore, a simple string-based JSON DSL would be the most intuitive for user configuration:

{
  "keymap": {
    "command": ["ctrl+A+B", "ctrl+A+ALT"]
  }
}

The system can't interpret this string directly, so it needs to be converted into an internal data structure.

For example, to support complex key combinations with AND/OR logic, we could design the DSL with a recursive ADT (Abstract Data Type) structure. This would be very fluent and expressive, but it also makes the DSL structure itself more complex to write.

Command: [
  {
    op: AND,
    keys: ['A', 'CTRL', { op: OR, keys: ['B', 'ALT'] }] // more combination
  }
]

Conversely, if we only allow simple shortcuts, a structure like the one you suggested would also be great:

Command: [
  { key: 'A', clt: true },
  { key: 'a', clt: true }
]

However, since I don't know the full scope of user configurations (Case-sensitivity, multi input , and so on) that gemini-cli will eventually allow, I felt that defining such a complex DSL at this stage would be an overspec.

Role of the Matcher and Implementation Direction

If we have a data-value-only DSL, we need a Decision Interpreter to parse it and determine the final action. I decided that representing this interpreter's interface using a Map would be more declarative and extensible. (Though it doesn't have to be a Map—a single function or another interface could work, but a Map seemed like the best fit.)

Therefore, the Matcher I've written represents the final form after the DSL has been interpreted. This means if a DSL existed, we could dynamically create the Matcher at boot-up by reading the DSL. Since the upstream DSL hasn't been defined yet, it currently only contains hard-coded lambdas.

The reason I didn't include text-buffer.ts in the Matcher implementation is that, as the name implies, it's about the buffer and handles more low-level manipulation. This role is different from the Matcher, which is closer to a 'key' interface. (This is my impression from looking at the code).

In the future, if an ADT-based DSL is implemented in the core, I expect text-buffer.ts would use this DSL data as config constants instead of magic numbers. For this reason, I intentionally excluded it from the higher-level Matcher implementation.

My understanding is that your suggestions were mainly about moving towards a data-driven DSL. I hope my explanation of the current approach and future direction makes sense in that context. Is my understanding correct?

Please feel free to share any more thoughts you have. I'd appreciate the feedback!

@jacob314 I've made some code changes to support a more data-driven config. I’d love to hear your thoughts on whether this is heading in a positive direction.

1. KeyBinding types and default bindings have been moved into the config.
   In the future, I hope to either parse these from a user-level config or use them directly in the settings interface.

   For now, the KeyBinding behavior remains almost identical to the existing ui/Key implementation. This is intentional to maintain backward compatibility — for instance, { sequence: '\x18', ctrl: true } should still work the same way. I deliberately avoided introducing a completely new type or breaking compatibility in this PR.

2. The Matcher dynamically generates an interface that reads the binding structure and evaluates whether it matches a specific command enum.

3. Some important caveats:

   • 3-1) After my initial changes, reverse search functionality was added, which led to the introduction of new enums. In these cases, the command differs slightly — for example, SUBMIT_REVERSE_SEARCH vs. SUBMIT. Although they are similar, their behavior diverges, so keeping them separate makes sense. However, I’m not yet sure what the best naming convention should be, and it’s also unclear how much of this will eventually be user-overridable. We’ll need to clarify this at some point.

   • 3-2) Currently, multi-key shortcuts (e.g., Ctrl + A + B) are not supported.

   • 3-3) As expected, since the config does not define a matching priority, a command that matches first may overshadow lower-priority commands.

/gemini review

Please let me know when you are ready for me to review again. Can't wait to have custom keyboard shortcuts.

@jacob314 I’ve resolved the conflicting parts.

By changing the hook in app.ts, conflicts occur whenever app.ts is updated due to changes such as depth. I fix it every time, but I can’t always keep my branch in sync with the main branch.