libvim

什么是libvim ？

libvim是 Vim 的一个分支，目标是提供最小的基于 C 的 API，对 Vim 模式编辑进行建模。它根本不包含任何用户界面（甚至没有终端 UI），主要负责充当快速缓冲区操作引擎，忠实于 Vim 击键。它仍在进行中，还有很多工作需要稳定。

如果您正在寻找终端 Vim，请查看 neovim，或者 GUI Vim，请查看 Onivim 2。

为什么？

libvim主要用于 Onivim 2。在 v1、v2 和其他项目之间实现了多次“UI Vims”迭代之后，我希望拥有的抽象是一种纯功能性 Vim，与终端 UI 完全解耦 - 其中“vim” ' 是(editor state, input) => (new editor state)的函数。由于 Onivim 2 完全处理渲染层，因此这个 Vim 建模的纯函数可以专注于缓冲区操作。

为此， libvim公开了一个简单的 C API 来与 Vim 配合使用，并支持监听缓冲区更改、消息等。

它负责：

• 管理和操作缓冲区
• 响应输入的缓冲区操作
• 解析和获取 VimL
• 处理按键重新映射

它不负责：

• 任何类型的 UI 渲染（终端等）
• 鼠标支持
• 语法高亮
• 拼写检查
• 终端支持
• 完成
• 输入法（IME）

所有这些都旨在由库的使用者来处理 - 让libvim专注于快速缓冲区操作的工作。

libvim构建跨平台（因为 Onivim 2 需要它！），以及 WebAssembly - 我们希望将 v1 教程移植到基于浏览器的体验。

这种“抽象 Vim”还有其他有趣的应用：

• WebAssembly 构建对于在浏览器/网站中实现 Vim 模式非常有用
• 原生构建对于需要 Vim 原生绑定的应用程序可能很有用 - 例如，它将成为实现readline的良好基础。

应用程序编程接口

有关 API 用法的示例，请查看 apitest，例如 normal_mode_motion。完整的 API 可以在这里找到：libvim.h

API 的核心是vimInput ，它采用单个密钥，并由状态机同步处理。缓冲区更新、消息等“副作用”可以通过像vimSetBufferUpdateCallback这样的回调来订阅。

该库正在积极开发中，我们目前不保证向后兼容性。使用 API 的风险由您自行承担。

编译

安装esy

esy就像本机代码的npm 。如果您还没有它，请通过运行以下命令来安装它：

 npm install -g [email protected]

获取来源

• git clone https://github.com/onivim/libvim
• cd src

安装依赖项

• esy install
• esy '@test' install

建筑

• esy build

运行测试

• esy '@test' build

发展

esy工作流程非常适合一次性构建，但每次都会重建世界，因此在开发过程中最好采用增量工作流程。

增量构建和运行测试

• cd src
• make apitest/autoindent.test.exe
• cd apitest
• ./autoindent.test.exe

针对 Onivim 2 测试更改

您可以通过在 Onivim 2 package.json中添加解决方案来针对本地构建的 Onivim 2 测试本地构建的libvim ，例如：

 "resolutions" : {
	...
	"libvim" : " link:../libvim/src "
}

只需确保它指向libvim/src文件夹即可。

注意：我们已经看到此工作流程存在问题，其中 Onivim 2 中的二进制文件可能已过期，因此我们建议在每次更改后运行rm -rf _esy && esy i以重建依赖关系。

常问问题

为什么libvim基于 Vim 而不是 Neovim？

我是 Neovim 团队正在做的工作的超级粉丝（该团队非常支持 Onivim 项目）。理想情况下，我们会坚持使用 Neovim 或基于libnvim实现libvim 。事实上，我第一次尝试构建这个“最小抽象” - 我尝试将其基于 Neovim 的libnvim 。我将调查时间限制为 2 天，并遇到了一些严重的障碍 - 我们的构建环境在 Windows 上有点具有挑战性（它基于 Cygwin + MingW 交叉编译器工具链） - 我在让 Neovim + deps 在该环境中构建时遇到了几个问题。根据这个峰值，我估计需要大约 3-4 周的时间才能让它在该工具链中运行。

请注意，这不是 Neovim 问题 - 依赖项的使用和CMake的利用是很好的决策 - 这是我们的 OCaml 构建系统的结果。 Cygwin + MingW 交叉编译器工具链并不能很好地处理所有依赖项（作为 Win32 和 Unix 的奇怪混合体，通常会出现 #ifdef 错误、引入不正确的依赖项的情况，这可能会耗费大量时间）努力解决这些问题）。

相比之下，Vim 能够在该环境中轻松编译（注意：如果有人有兴趣构建跨平台、启用esy的 Neovim 包 - 我们可以重新访问它！）。我还对 WebAssembly 构建感兴趣，用于将 Onivim v1 教程移植到网络上，其中这个编译为 WebAssembly 的 C 抽象库将是一个完美的选择。

除了构建问题之外，Neovim 和 Vim 都需要重构才能提供同步的功能性 API：

• Neovim 在其核心使用事件循环，需要将其短路或删除才能提供该 API
• Vim 使用阻塞输入，需要将其反转以支持功能性 API

所有这些工作的动机是从 Onivim v2 中删除 RPC 层以减少复杂性和故障模式 - 最终，这纯粹是基于约束的技术决策。如果我们可以使用nvim获得类似的 API，可以通过esy跨平台构建 - 我很乐意使用它:)

配套

如果您对libvim感兴趣，并且您想支持开发，请考虑以下事项：

• 预购 Onivim 2
• 对 Patreon 的支持

贡献

如果您想帮助改进libvim ，请参阅 CONTRIBUTING.md 文件。

一些贡献的地方：

• 帮助我们添加测试用例
• 帮助我们删除libvim不需要的代码或功能
• 帮助我们从 Vim 移植补丁

执照

libvim代码已根据 MIT 许可证获得许可。

它还依赖于第三方代码，特别是 Vim，但也依赖于其他代码 - 有关许可证详细信息，请参阅 ThirdPartyLicenses.txt。