-
Notifications
You must be signed in to change notification settings - Fork 822
Feature Request: Support customizable keybinding for inserting newlines (e.g., Shift+Enter) #794
Description
功能请求:支持自定义插入换行的快捷键 / Support customizable keybinding for inserting newlines
问题描述 / Problem Description
目前 kimi-cli 中插入换行的快捷键固定为 Ctrl-J 和 Alt-Enter。然而:
Alt-Enter在某些终端(如 VS Code 内置终端、部分版本的 iTerm2)可能无法正常工作- 不同用户有不同的使用习惯,部分用户(如从 opencode 迁移过来的用户)更习惯使用
Shift-Enter
技术调研 / Technical Research
我调研了 opencode 的实现方式,以下是技术细节:
1. opencode 的默认配置
"input_newline": "shift+return,ctrl+return,alt+return,ctrl+j"2. 键盘协议支持
opencode 使用 kitty keyboard protocol 和 xterm modifyOtherKeys 来检测带修饰键的 Enter:
| 协议 | 转义序列 | 说明 |
|---|---|---|
| kitty | \x1b[13;2u |
Shift+Enter |
| xterm modifyOtherKeys | \x1b[27;2;13~ |
Shift+Enter |
| - | \x1b[27;5;13~ |
Ctrl+Enter |
| - | \x1b[27;6;13~ |
Ctrl+Shift+Enter |
3. 终端兼容性
opencode 文档指出,部分终端需要手动配置才能发送修饰键信息:
Windows Terminal 配置示例:
"actions": [
{
"command": {
"action": "sendInput",
"input": "\u001b[13;2u"
},
"id": "User.sendInput.ShiftEnterCustom"
}
],
"keybindings": [
{
"keys": "shift+enter",
"id": "User.sendInput.ShiftEnterCustom"
}
]支持的终端:
- ✅ Kitty(原生支持)
- ✅ iTerm2(原生支持)
- ✅ Windows Terminal(需配置)
- ✅ Alacritty(需配置)
建议的实现方案 / Proposed Solutions
方案 A:配置文件支持(推荐)
添加 keybindings 配置项,允许用户自定义快捷键:
[keybindings]
insert_newline = ["c-j", "escape enter", "shift-enter"]实现要点:
- 扩展
Config类添加keybindings字段 - 修改
CustomPromptSession读取配置并应用键绑定 - 对于
Shift-Enter等需要特殊处理的键,使用底层的键盘监听(类似现有的keyboard.py)
优点:
- 灵活性高,用户可按需配置
- 向后兼容,默认行为不变
方案 B:添加 Shift-Enter 作为默认选项
在默认键绑定中增加对 Shift-Enter 的支持(如果终端支持)。
实现要点:
- 扩展
keyboard.py识别 kitty/xterm 的扩展键盘序列 - 在
prompt.py中处理SHIFT_ENTER事件
优点:
- 对支持该功能的终端用户无缝体验
- 无需用户配置
缺点:
- 在不支持的终端上无效,可能造成困惑
可能的实现代码参考 / Implementation Reference
基于我的调研,以下是可能的实现思路:
# config.py
class KeybindingsConfig(BaseModel):
insert_newline: list[str] = Field(
default_factory=lambda: ["c-j", "escape enter"],
description="Keybindings for inserting a newline",
)
# keyboard.py - 扩展支持的序列
_SHIFT_ENTER_SEQUENCES = {
b"\x1b[13;2u", # kitty protocol
b"\x1b[27;2;13~", # xterm modifyOtherKeys
}
# prompt.py - 应用配置
# 处理标准键绑定 + 特殊键绑定(如 shift-enter)讨论点 / Discussion Points
-
是否值得支持 Shift-Enter?
- 优点:与 opencode、VS Code 等工具保持一致的用户体验
- 缺点:需要终端支持,且不同终端配置方式不同
-
配置格式的设计
- 使用 prompt_toolkit 的键名格式(如
c-j,escape enter)? - 还是使用更易读的格式(如
ctrl+j,alt+enter)?
- 使用 prompt_toolkit 的键名格式(如
-
是否只实现配置支持,还是同时添加 Shift-Enter 作为默认选项?
-
文档和错误处理
- 如何处理无效/不支持的键绑定配置?
- 是否需要提供终端配置指南?
环境信息 / Environment
- OS: macOS / Linux / Windows
- Terminal: iTerm2, Kitty, VS Code Terminal, Windows Terminal 等
- kimi-cli version: latest
我很乐意根据讨论结果来实现这个功能,并提交 PR。期待维护团队的反馈!
Feature request: Support customizable keybinding for inserting newlines / Support customizable keybinding for inserting newlines
Problem Description / Problem Description
Currently, the shortcut keys for inserting newlines in kimi-cli are fixed to Ctrl-J and Alt-Enter. However:
Alt-Entermay not work properly in some terminals (such as VS Code built-in terminal, some versions of iTerm2)- Different users have different usage habits. Some users (such as those who migrated from opencode) are more accustomed to using
Shift-Enter
Technical Research / Technical Research
I investigated the implementation of opencode, and the following are the technical details:
1. Default configuration of opencode
"input_newline": "shift+return,ctrl+return,alt+return,ctrl+j"2. Keyboard protocol support
opencode uses kitty keyboard protocol and xterm modifyOtherKeys to detect Enter with modified keys:
| Protocol | Escape Sequence | Description |
|---|---|---|
| kitty | \x1b[13;2u |
Shift+Enter |
| xterm modifyOtherKeys | \x1b[27;2;13~ |
Shift+Enter |
| - | \x1b[27;5;13~ |
Ctrl+Enter |
| - | \x1b[27;6;13~ |
Ctrl+Shift+Enter |
3. Terminal compatibility
The opencode documentation points out that some terminals require manual configuration to send modifier key information:
Windows Terminal configuration example:
"actions": [
{
"command": {
"action": "sendInput",
"input": "\u001b[13;2u"
},
"id": "User.sendInput.ShiftEnterCustom"
}
],
"keybindings": [
{
"keys": "shift+enter",
"id": "User.sendInput.ShiftEnterCustom"
}
]Supported Terminals:
- ✅ Kitty (native support)
- ✅ iTerm2 (native support)
- ✅ Windows Terminal (configuration required)
- ✅ Alacritty (configuration required)
Suggested Implementation Solution / Proposed Solutions
Solution A: Configuration file support (recommended)
Add keybindings configuration item to allow users to customize shortcut keys:
[keybindings]
insert_newline = ["c-j", "escape enter", "shift-enter"]Implementation points:
- Extend the
Configclass to add thekeybindingsfield - Modify
CustomPromptSessionto read the configuration and apply key bindings - For keys that require special processing such as
Shift-Enter, use the underlying keyboard monitor (similar to the existingkeyboard.py)
Advantages:
- High flexibility, users can configure it as needed
- Backwards compatible, default behavior unchanged
Option B: Add Shift-Enter as default option
Add support for Shift-Enter in default keybindings (if supported by the terminal).
Implementation points:
- Extend
keyboard.pyto recognize extended keyboard sequences of kitty/xterm - Handle the
SHIFT_ENTERevent inprompt.py
Advantages:
- Seamless experience for end users who support this feature
- No user configuration required
Disadvantages:
- Does not work on unsupported terminals, may cause confusion
Possible implementation code reference / Implementation Reference
Based on my research, the following are possible implementation ideas:
#config.py
class KeybindingsConfig(BaseModel):
insert_newline: list[str] = Field(
default_factory=lambda: ["c-j", "escape enter"],
description="Keybindings for inserting a newline",
)
# keyboard.py - Extended supported sequences
_SHIFT_ENTER_SEQUENCES = {
b"\x1b[13;2u", # kitty protocol
b"\x1b[27;2;13~", # xterm modifyOtherKeys
}
# prompt.py - application configuration
# Handle standard key bindings + special key bindings (such as shift-enter)Discussion Points / Discussion Points
-
**Is it worth supporting Shift-Enter? **
- Advantages: consistent user experience with opencode, VS Code and other tools
- Disadvantages: Terminal support is required, and different terminal configuration methods are different
-
Design of configuration format
- Use prompt_toolkit's key format (e.g.
c-j,escape enter)? - Or use a more readable format (eg
ctrl+j,alt+enter)?
- Use prompt_toolkit's key format (e.g.
-
**Is only configuration support implemented, or is Shift-Enter also added as a default option? **
-
Documentation and Error Handling
- How to deal with invalid/unsupported keybinding configurations?
- Is a terminal configuration guide required?
Environment Information / Environment
- OS: macOS / Linux / Windows
- Terminal: iTerm2, Kitty, VS Code Terminal, Windows Terminal, etc.
- kimi-cli version: latest
I'd be happy to implement this feature based on the discussion and submit a PR. Looking forward to feedback from the maintenance team!