tab键行为由tab_completion和auto_complete_commit_on_tab共同控制:前者决定tab是否补全,后者决定补全框弹出时tab是否确认;二者需配合实现完整补全链路。

Tab 键到底是在补全,还是在缩进?
Sublime 默认的 tab_completion 行为和 auto_complete 是两套逻辑:前者管“按 Tab 是否填充候选词”,后者管“要不要弹出补全框”。很多人关了 auto_complete 却发现 Tab 还在乱补,就是没动对开关。
-
tab_completion设为false:Tab 永远只插缩进,哪怕补全框开着也不确认项 -
auto_complete_commit_on_tab设为true:只有补全框已弹出时,Tab 才能选中高亮项(否则还是缩进) - 两者同时开启,才构成“敲几个字母→自动弹窗→Tab 确认”的完整链路
- 如果只想要手动补全(比如 Ctrl+Space 唤起再 Tab),就关
tab_completion,但留auto_complete_commit_on_tab
Python/JS 文件里 Tab 在字符串里也补全,怎么拦住?
这不是 bug,是 Sublime 的默认 scope 匹配太宽——它不区分你是在写代码还是写字符串。靠 auto_complete_triggers 限定触发范围,是最稳妥的解法。
- 在
Preferences → Settings – Syntax Specific(打开一个 .py 文件后调出)中添加: "auto_complete_triggers": [ {"selector": "source.python - string - comment", "characters": "."} ]- 其中
source.python是 Python 主体,- string排除所有字符串 scope(如string.quoted.double.python),- comment同理 - 注意:JavaScript 要写
source.js - string - comment,不能复用 Python 配置 - 这个配置不会影响
Ctrl+Space手动唤起,只约束“自动弹窗+Tab 确认”这条路径
禁用自动补全后,Tab 缩进还正常吗?
完全正常。auto_complete 和缩进设置(tab_size、translate_tabs_to_spaces)毫无关系。关掉补全,Tab 依然按你的缩进规则走。
- 验证方式:设
"auto_complete": false后,在任意文件里敲 Tab,看是否插入空格或制表符 - 常见误操作:有人顺手把
tab_completion也关了,结果发现 Tab 不缩进了——其实是自己改错了设置项 - 真正控制缩进的是
detect_indentation、tab_size、indent_subsequent_lines这些,和补全无关
为什么关了 auto_complete,Emmet 还在抢 Tab?
Emmet 是独立插件,它的 Tab 行为不走 Sublime 原生补全流程,而是监听按键事件直接拦截。所以关原生设置对它无效。
- 解决路径:打开
Preferences → Package Settings → Emmet → Settings - 找到
"disable_auto_insert",设为true;或删掉"tab_key_activation"相关配置 - 更彻底的办法:在 Emmet 的 Key Bindings 里移除
{"keys": ["tab"], ...}绑定 - 注意:Emmet 关闭后,
.container+ Tab 这类快捷展开就失效了,得权衡是否真要禁用
Tab 补全开关背后牵扯三套机制:原生单词补全、语法感知触发器、插件级按键劫持。最容易被忽略的是——同一份设置,在不同语法文件里可能完全不生效,因为 Settings – Syntax Specific 的优先级高于全局设置,而很多人根本没意识到自己正在编辑的是“Python 专属配置”。











