我从很早以前就开始使用 Sublime Text。Sublime 的定位是轻量级编辑器，性能好速度快，十年前非常火。不过后来渐渐被 VS Code 等新工具盖过了风头。最近几个月我开始尝试做些 macOS 上的小工具，经常需要看 Swift 代码。但 Xcode 太庞大了，我甚至都没装（只装了命令行工具）。VS Code 对我来说也稍微有一点重，所以还是希望继续用 Sublime 来读代码。
注：目前最主流的 Swift 工具是 Xcode 和 VS Code，前者和后者的 Swift 插件都是苹果官方维护的。
但用 Sublime 看 Swift 代码有个痛点：Sublime 官方一直没有内置 Swift 支持。而去 Package Control（Sublime 的官方插件商店）里搜，排名靠前的几个 Swift 插件（在我开始动手做的时候）全都停留在好几年前——有的甚至是十年前 Swift 1⁄2 时代的产物；稍微好一点的是两年前更新的，但也只支持到 Swift 5.6。
于是我就动手做了一个，方便自己阅读代码。写完之后，心想做都做了，不如顺手提交到 Package Control 上，这样也可以让别人用。没想到在提交 PR 的时候，遇到了一段意料之外的经历。
因为插件商店里已经有叫 Swift 的插件了，我就把自己的插件起名叫 Swift6。我当时的想法很简单：反正上面已经有好几个 Swift 插件了，多我一个不多，少我一个不少。在我看来，网上同一个功能存在一堆竞品是再正常不过的事，用户爱用哪个用哪个，如果有人正好需要看最新的 Swift 6 代码，自然会选我这个。
结果 PR 提上去之后，神奇的事情发生了。
Package Control 的核心维护者们看法跟我完全不一样。他们非常克制，不希望基础语言的语法插件继续碎片化下去。用户只需要一个完好能用的，而不是几个各有缺陷的。
核心维护者 @braver 和负责 Sublime 官方内置语法库的 @deathaxe 在 PR 里聊了起来，顺便给我科普了一段历史：原来过去很多年里，社区先后尝试过两次想孵化一个能够内置进官方的标准 Swift 语法插件，但都半途而废了，结果就是老插件断更多年却安装量巨大，新插件又各有缺陷。
@deathaxe 审查了一遍我的实现，认为整体架构很干净，甚至可以向下兼容 Sublime Text 3。最终他们拍板了一个让我受宠若惊的决定：别叫什么 Swift6 了，直接由我接管那个 97K 安装量的元老级 Swift 插件，用我这套新实现顶替它！（Package Control 里可以实现这种变更，其实就是把某个名字的插件从原先指向的仓库改为另一个仓库）
更让人感慨开源社区氛围的是：@braver 本来在评论里说“那个老项目看起来已经彻底凉了，按规矩我们给十年前的原作者 @quiqueg 留两周时间看是否反对”，结果话音刚落 2 分钟，@quiqueg 居然就在 PR 里闪现秒回了！他不仅爽快地表示双手赞成，承认其它实现可能好得多。甚至还主动帮我把他十年前的最后一个旧版本（供远古 ST2 用户怀旧使用）打包成了无历史记录的孤立分支，让我作为历史记录同步到我的分支里。
后面我又完成了几个合并前的准备工作，最终发布到了 Package Control 上。现在所有安装了 Swift 插件的老用户会自动升级到我这个新实现上。而新用户在 Package Control 上搜索 Swift 也会优先找到这个用户量很大的插件。这样实现了对 Sublime Text 社区的最大收益。
本来只是为了自己看代码方便随手造的小轮子，莫名其妙就成了 9.7 万存量用户的“正统继承人”，突然感觉肩上多了一份沉甸甸的责任感 😅
- 项目地址： https://github.com/hanguokai/sublime-swift
- Package Control 地址： https://packagecontrol.io/packages/Swift
