vim_mode插件无法完全复现Vim状态机，存在可视模式嵌套、寄存器操作及ci"等文本对象解析缺陷；粘贴后光标错位因Sublime与插件剪贴板处理不一致；Ctrl+D冲突需通过键绑定配置区分多选与滚动。
vim_mode 在 Sublime Text 中不是原生功能，而是通过插件实现的模拟行为。它无法完全复现 Vim 的状态机逻辑，尤其在可视模式嵌套、寄存器操作和自定义操作符（如 daw、cit）上存在明显断层。
如果你已习惯 Vim 的肌肉记忆，又想在 Sublime 中保留部分效率，必须清楚哪些行为能“差不多”，哪些会突然卡住。
为什么 vim_mode 插件总在粘贴后崩掉光标位置
这是最常被忽略的兼容性坑：Sublime 的剪贴板与 Vim 模式插件对 "* 和 "+ 寄存器的处理不一致。插件默认把系统剪贴板映射为 "*，但 Sublime 自身的 paste 命令不走 Vim 寄存器路径，直接插入文本并重置光标到行尾。
- 临时解决：粘贴前先按
Esc确保退出插入模式，再用Ctrl+V；不要依赖p或P - 长期规避：在插件配置中禁用寄存器同步，改用
Ctrl+Shift+V（带格式粘贴）替代 - 根本原因：Sublime 的 API 不暴露底层光标重置钩子，插件只能监听
on_modified事件做补偿，但时机不可控
ci" 类文本对象操作在 Sublime 中为何经常选错范围
Sublime 没有 Vim 那种基于语法树的文本对象解析器。它的 ci" 实际只是正则匹配最近的双引号对，不识别字符串转义、嵌套引号或注释内引号。
- 典型失败场景：在
console.log("He said \"hi\"");中执行ci"，会错误选中从第一个"到末尾的"，跳过中间的转义 - 安全替代：先用
Ctrl+Shift+M（选择括号内容）定位字符串容器，再手动调整选区 - 性能影响：开启
enable_auto_indent后，这类操作会触发额外缩进计算，响应延迟更明显
如何让 Ctrl+D 多选和 Vim 模式共存不打架
Sublime 原生的 Ctrl+D（逐个添加相同词）与 Vim 插件的 Ctrl+D（向下滚动半页）冲突是默认行为。不改键位就等于主动放弃多光标编辑这个 Sublime 最大优势。
- 必须修改插件键绑定：在
Preferences → Package Settings → Vintageous → Key Bindings – User中覆盖 - 推荐配置：
[ { "keys": ["ctrl+d"], "command": "find_under_expand", "context": [{ "key": "setting.command_mode" }] }, { "keys": ["ctrl+d"], "command": "scroll_lines", "args": {"amount": 5.0}, "context": [{ "key": "setting.command_mode", "operator": "equal", "operand": false }] } ] - 注意：某些插件（如
EasyMotion）会劫持Ctrl组合键，需检查插件加载顺序
真正难调试的从来不是功能有没有，而是某个操作在 90% 场景下正常，剩下 10% 却静默失败——比如 gq 格式化时遇到注释里的 URL 就直接跳过整段，连错误提示都没有。这时候别查文档，直接看插件源码里 re.sub 的 pattern 是否写了 re.DOTALL。
