分享我开发 Quick Nav 插件的经历和上架历程，希望能给想要开发 Obsidian 插件的朋友一些参考。
这个插件补全了 Obsidian 内并不提供的光标移动的快捷键自定义功能，让用户可以在编辑区域灵活移动光标，免去频繁使用鼠标和方向键的麻烦。
源起
每个工具的诞生都源于一个需求。作为一名长期使用 VS Code 的开发者，我已经习惯了自定义的光标移动快捷键。在 Obsidian 码字，被光标移动弄得十分不爽，特别是在 Windows 环境下，失去了 MacBook 触控板的便利性，右手移来移去太过让人烦躁了。
我想："为什么不把那些我在 VS Code 中习惯的光标操作带到 Obsidian 中呢？"这就是 Quick Nav 插件的起点。
为什么不使用 vim 模式？
有很多插件提供了 vim 或者类 vim 的操作，为什么不直接用？很简单，vim 模式本来就是反直觉的。Obsidian 不是代码编辑器，普通人用来写文字，就是正常的打字，用 vim 模式来满足移动光标的需求就是让普通人学习使用大炮来打蚊子。
编写：从复杂到简单的转变
开始的迷途
按照 Obsidian 官方模板创建项目后，我顺便尝试直接让 AI 生成代码。目标很明确：复刻我在 VS Code 中使用的光标移动功能。
AI 的做法是直接使用 Selection API 来操纵光标。对于横向移动（左右移动），实现相对简单。但当涉及到垂直移动（上下移动）时，问题变得异常复杂。比如不同字号，字体，text-wrap，在影响排版同时实际也影响了下一行的位置究竟在哪。哪里才是用户实际期待的位置？AI 给出了非常复杂的算法，即使经过了我十几次指示来修改，仍然存在各种边缘情况的 bug。
思维转变的关键时刻
在经历了多次失败尝试后，我意识到需要转变思路，从更高的维度来看待这个问题。
VS Code 之所以能实现这些功能，是不是因为它自己重写了界面渲染？所以能做到精确控制？同为商业产品的 Obsidian 应该也已经解决了这些问题？
通过查阅 Obsidian 官方文档，我发现它内部实际是嵌入了 Code Mirror。进一步研究 Code Mirror 的文档后，发现 Code Mirror 本身就提供了非常完整的光标移动功能。问题是 Obsidian 官方并没有将这些功能暴露出来。
有趣的是，通过全网搜索和浏览官方论坛，我发现虽然有用户提出类似需求，但既没有插件实现，官方也似乎没有计划添加这一功能。
柳暗花明
一旦找到了正确的方向，剩下的工作变得出奇简单。核心代码仅需调用一两个 Code Mirror 提供的函数即可，不需要 AI 了。
不过，我还是让 AI 帮忙生成了中英日说明文档和相关文案。这部分让 AI 来做倒是十分合适。
上架：耐心与坚持的考验
漫长的等待
插件在 25 年一月份就已经完成了。我在官方仓库提交了 PR，但随后是长达一两个月的沉默。不知道是因为假期还是其他原因，总之是等了好久，但看着官方仓库里几十上百个 PR，我想可能的确是忙不过来吧。
问了问已经上架过插件的朋友，说是挺快就上架了，也不清楚为啥，我也没辙了，只能等。
多次修改
提交的插件会先被机器人审阅代码，会提示哪些代码不符合要求，过了机器人审阅，才会有人工的审阅。一开始我的插件默认直接绑定好了快捷键，机器人就不让过。
Obsidian 官方的人工审核异常严格。许多我参考老插件和知名插件的代码写法都被驳回了，我猜可能是因为代码逐渐完善，就禁止了一些写法吧，但是已经上架了的插件就算了。
最令人意外的是，审核人员直接质疑了插件的存在价值。
如果真有用，我干嘛要写一个插件嘛？
整个审核过程中，我修改了四五个版本。每次修改都需要重新排队等待审核，这是一个考验耐心的过程。
终于过了
经过多轮修改和沟通，Quick Nav 终于通过了审核，正式上架到 Obsidian 的插件市场。我看了看上架不到一天有 6 个下载。倒不是很在意这个数目，因为我的目的只是为了自己用得爽，发到官方仓库就不用手动安装了，哈哈。
经验与思考
这次开发经历给我带来了几点重要启示：
- 站在巨人的肩膀上：有时候，最佳解决方案不是重新发明轮子，而是找到并利用已有的工具和库。
- 简单胜于复杂：当你发现自己的解决方案变得异常复杂时，可能是走错了方向。
- 官方审核严格：Obsidian 的插件审核过程漫长而严格，耐心很重要，还有就是不要怂。
如果你对 Obsidian 插件开发感兴趣，欢迎查看 Quick Nav 的 GitHub 仓库。如果想直接用，在 Obsidian 插件市场搜索 "quick nav" 即可。
