为 VSCode、Sublime Text 和 Notepad++ 编写插件（第一部分）
5.00/5 (3投票s)
VSCode、Sublime Text 和 Notepad++ 插件开发技术比较
续篇请访问：第二部分
引言
这并非一篇技术文章，而是一个关于 Notepad++、Sublime Text 和 VSCode 插件开发模式的概述。它分别介绍了每个平台的概况，以及每个平台特有的机会和一些挑战。
一位用户问我最喜欢哪个编辑器。嗯，答案无法在电子邮件的有限格式中说清楚，所以这篇文章诞生了。它篇幅较长，我将其分为两部分，以便阅读。但如果你迫不及待，可以在 GitHub 上访问整篇文章的内容。
背景
我处于一个相当独特的位置，因为我开发了一个复杂的插件（以及一些更简单的插件），它已被移植到所有三个平台的编辑器中：Notepad++、Sublime Text 和 VSCode。
本文内容是我个人经验的反映，应以该角度来看待。许多人可能不同意我的结论，事实上我也有此预期，因为我的目标并非提供一个最终的、无可争议的对这些精彩平台的评估。
我的目标是让开发者了解在开始为上述编辑器进行开发时可以期待什么。同时，也让编辑器维护者有机会了解他们提供的开发者体验的不足之处，并可能加以改进。
平台概述
Notepad++ (N++)
目标读者
海量。适合从初学者到高级程序员的任何人。N++ 是推广您产品的最佳载体。因此，在发布其 N++ 插件后，CS-Script 的使用量急剧增长。目前，该插件的总原始下载量已超过 1,000,000。
用户体验
非常好。拥有庞大的插件库。插件种类非常丰富，令人印象深刻。它涵盖了 UI 和非 UI 插件。缺点是仅在 Windows 上可用。
这是 N++ 版 CS-Script 插件的外观和感觉。它实现了非常类似 VS 的外观和体验。
开发者体验
很遗憾，这是我最不喜欢的三个平台。
从设计质量来看，托管模型相当普通。他们未能认识到跨平台运行时托管插件的重要性，而是选择了原生运行时，即 C/C++。即使您使用 .NET 或 Python 的桥接，也需要完全单独维护 x64 插件（单独构建和二进制存储库）。
试想一下，ST3 和 VSCode 插件可以在所有操作系统上运行，但对于 N++（仅在 Windows 上运行）您需要维护两个独立的插件（x86 vs x64）。
API 本身还有很多不足之处。它非常有限且极其过时。N++ 只提供了一个非常精简的自有 API，并将开发者简单地引导至旧的 Scintilla 渲染引擎 API。而 Scintilla 是一个老派的庞然大物。它假装自己还停留在 2000 年。有时甚至迫使您将文本视为字节数组而非字符（选定长度是选定字节的数量）。
Scintilla 提供了出色的渲染效果，但仅此而已。它在其他功能方面很难令人印象深刻。工具提示不具备交互性。无法对工具提示和自动完成进行样式设置。值得庆幸的是，N++ 允许您挂钩其自身的窗口管理，因此您可以创建自定义面板/视图。这意味着通过深入底层，您可以实现几乎任何您想要的外观（例如，树形视图、列表、托管浏览器）。
插件管理
插件管理令人费解。他们实现了一个非常好的插件管理器，但公共存储库更新非常缓慢，以至于如果有人在插件中犯了错误，他需要等待大约 3-4 个月才能让他的修复触达用户。
支持和社区
文档相当简略。专门的讨论区既不健全也不太有用。
N++ 的支持令人震惊。开发人员可能非常努力工作，但没有太多时间或机会与插件开发者互动。曾有一次，一次特定的 N++ 更新引入了一个严重的错误，完全破坏了所有比单个 DLL 复杂且依赖于自己文件/文件夹结构的插件。有一天一切正常，第二天就开始报告多个插件“与 N++ 不兼容”。
该问题被记录下来，并明确指出了其毁灭性的严重性。数周内没有响应。我曾（徒劳地）尝试在 Twitter 和其他公共平台上追踪团队协调员。未果。直到我的插件用户和其他插件作者在 N++ 论坛上抱怨，问题才被承认并……勉强修复。
唯一积极的开发体验是可以使用调试器。另一个好处是，作为原生程序，几乎可以实现任何功能。
底线
尽管设计笨拙，N++ 提供了出色的用户体验。然而，如果您要为其开发，请做好心理准备。您将孤军奋战。该平台要求开发者付出最高的努力成本，但几乎不对他们可以实现的功能设限。
Sublime Text 3 (ST3)
目标读者
Sublime 是一款极其受欢迎的编辑器。它被誉为一款精密的编程工具，专业人士可以真正欣赏它。我倾向于同意。初学者可能会觉得它功能过多而难以使用，但经验丰富的开发者则钟爱它的一切。
用户体验
脑海中浮现出一个词——流畅。它很出色。闪电般的速度。是三者中启动最快的。定制的程度超乎想象。
有时，定制化甚至会与便利性产生冲突。因此，在 VS、VSCode 和 N++ 中经常使用列选择，我发现 ST3 上（通过多光标模式）的实现有点“顽固”。
拥有庞大的插件库。支持所有操作系统。
不过，一个明显的缺点是开箱即用缺乏打印支持。对于如此全面的编辑器来说，没有如此基本的功能，至少可以说是相当令人费解的。需要安装少数几个打印插件才能启用打印（通常通过系统网络浏览器）。
开发者体验
非常好。托管模型设计得很出色。托管运行时和语言是 Python。
API 本身设计精良。一切都很有道理。简单、逻辑清晰且可预测。总之——优雅。当某些功能原生不支持时，您可以退而求其次执行 IDE 命令。工具提示使用轻量级 HTML 引擎进行渲染。出色。您可以在其中放置按钮并实现复杂的样式。很棒。
API 的缺点是它被封闭了。API 实际上已经停止了演进，封锁了其功能状态。
例如，无法通过 API 关闭已打开的文件。您必须将焦点切换到所需的文件标签页，然后执行“关闭”命令（相当于菜单->文件->关闭）。这意味着您必须打断焦点。这意味着糟糕的用户体验。对于更复杂的情况，焦点管理会成为一个真正的问题。也无法扫描键盘状态。
另一个令人沮丧的设计决策是完全禁止任何自定义面板。就这样，ST3 多年来一直抵制开发者对这项功能的需求。您无法创建自定义面板。您最多只能打开一个文件，放置一些特殊文本来模仿丰富的 UI 元素（例如，树形视图）。我曾用“收藏夹”和“CodeMap”插件走过这条路。
支持和社区
非常出色。是最好的。如果您提出问题，很可能会得到确切了解情况的人的回答。总的来说，ST3 社区的平均成员水平非常高。偶尔，您可能会感受到宗教般的评论，但非常温和。有一点是肯定的，如果有答案而您只是不知道在哪里找到它，ST3 论坛就是您寻找答案的地方。文档结构清晰，为您提供了关于整体功能和可能性的良好概述。其他所有方面——讨论区。
插件管理
插件管理很巧妙。编辑器可以从您的本地文件、您的个人 GitHub 存储库或通过官方基于 GitHub 的存储库路由器插件管理器获取插件。插件开发者完全控制其插件的生命周期。
最大的缺点（除了 API 停滞外）是缺乏集成调试器。如果您的插件行为复杂，那么您就倒霉了，只能依赖 Python 的“print()”。这也有一个间接的缺点：在 ST3 下，没有语言插件可以实现真正的调试器运行时集成。
另一个缺点是侧边栏插件开发。您无法同时安装一个插件并进行开发/故障排除。好吧，这只对未压缩的插件可行，而这些插件在官方是不被鼓励的。
我无法忽略另一个意外的不便。ST3 插件指南要求您以压缩形式分发软件包。虽然这对 ST3 开发团队有一定的好处，但对于插件开发者来说，对这些插件进行故障排除是一场噩梦。唯一例外的是包含可执行文件的插件，这些插件在运行时需要以解压形式存在。
因此，当我尝试以未压缩的形式发布我的 CodeMap 插件时，ST3 团队的一名成员联系了我，并礼貌地要求我遵守规则，压缩该插件。我相信如果我开始一场漫长无聊的争论，他们会允许我按我的方式做，但……我宁愿有选择，而不是不得不为我的动机辩护。尽管 ST3 团队可以轻易地反驳这一点。
底线
轻巧、动态且高度可定制。可以说，它面向的受众稍微更高级一些。在为插件开发者施加某些限制的同时，提供了几乎完美的用户体验。
该平台对开发更简单/更小的插件稍微友好一些。虽然完全有可能开发复杂的、功能全面的插件，但需要付出更高的努力成本。
未完待续（第二部分）