
Sublime Text 4 的更新日志篇幅不长,但里面有三处属于结构性改动:插件进程模型、内置 Python 版本、渲染方式。这三处决定了不少实际现象——插件报错为什么不再拖垮编辑器、几年前的插件为什么突然失效、以及为什么有些机器上会出现闪烁。
下面按这三处展开,顺带把索引和配置合并这两块讲清楚。
在 Sublime Text 3 里,所有插件跑在同一个 Python 进程中。这意味着一个插件写出死循环,或者触发段错误,整个编辑器会一起失去响应——用户看到的是"编辑器卡死",实际原因可能只是一个第三方插件的空转。
Sublime Text 4 把插件宿主拆成了独立进程,带来两个直接后果。
编辑器不再被插件拖死。 插件崩溃时影响面收窄到该宿主进程,编辑器本身仍可操作,控制台会留下错误信息。
插件之间的隐式共享消失了。 在旧模型里,两个插件可以靠模块级变量互通状态;拆成多个宿主后,这种做法不再可靠。依赖共享全局状态的插件,升级后可能出现"单独看都正常、组合起来不对"的现象。
排查入口是控制台:插件抛出的异常、宿主进程的退出信息都会打在这里。
这是"老插件失效"的主要原因。
两者的跨度有五个大版本,一些后来才有的语言特性在旧宿主里根本不存在:
而 Sublime Text 4 的 sublime.py 现在带类型标注,在编辑器内写插件时能得到参数补全和签名提示,对维护稍大一点的插件帮助明显。
迁移时最需要注意的不是语法,而是异常处理。 旧插件常把导入失败静默吞掉,于是在新宿主里表现为"插件装了但什么也不做"。打开控制台看导入错误,比反复卸载重装有效。
Sublime Text 4 开始尝试硬件加速。在多数环境下它带来的收益是滚动更顺、大文件翻页更稳。
但有一类环境不适合打开它:
这些环境下常见现象是闪烁、残影、局部白屏,属于渲染路径问题,而不是文件问题。判断方式很直接:把渲染方式改回软件模式,现象消失即可确认。设置项是 hardware_acceleration,值改回 none。
这一版换了索引引擎,支持跨文件的符号跳转,代价是索引过程本身有成本。
索引数据写在配置目录的 Local 下,首次打开一个大型仓库时会持续占用 CPU 和磁盘。如果项目里包含依赖目录,比如前端项目的 node_modules、PHP 项目的 vendor,这部分会被一起扫描,收益却接近零。
在项目设置里排除掉:
索引异常时可以整体重建。 表现为跨文件跳转失效或指向错误位置时,删掉 Local 下的索引目录,重启后会重新生成,不影响任何个人设置。
"设置不生效"多数是合并顺序的问题。优先级从低到高是:
高优先级覆盖低优先级,且按项覆盖而不是整段替换——项目里只写一行,不会清掉用户设置里的其他项。
要注意语法特定设置的层级比用户设置高。如果你给某类文件单独设过缩进,再改用户设置里的缩进是不会生效的。
构建系统是一个 JSON 文件,放在 Packages/User 下。下面这个用于 Python,把脚本路径与工作目录都对齐,并在捕获异常时提供可跳转的行号:
{
"cmd": ["python", "-u", "$file"],
"file_regex": "%5E File \"([%5E\"]%2B)\", line ([0-9]%2B)",
"working_dir": "$file_path",
"selector": "source.python",
"variants": [
{ "name": "Run", "cmd": ["python", "-u", "$file"] }
]
}几个变量的含义:$file 是当前文件完整路径,$file_path 是其所在目录。-u 关闭输出缓冲,否则 Python 的输出会攒到进程结束才一次性刷新,看起来像"程序没反应"。
file_regex 决定报错能不能点击跳转。上面的写法是按 Python traceback 的格式来的,换成其他语言需要相应调整捕获模式。
三处结构性改动对应三类现象:
再加上索引与配置合并这两块,使用 Sublime Text 4 时遇到的多数"玄学问题"都能找到确定的原因,而不必靠反复重装解决。
安装包地址:
https://www.ijinshan.com/software/SublimeText4.html?channel=4028
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。