Xi编辑器

维护状态： *xi-editor项目目前已停止开发。尽管我们乐意接受错误修复，但目前没有计划添加新功能。您可能对Lapce编辑器感兴趣，它可以被视为xi-editor的精神继承者。 —— 编辑团队

注意： 此存储库仅包含编辑器核心，不能单独使用。有关基于它的编辑器，请查看前端列表。

xi-editor项目旨在使用现代软件开发技术构建一个高质量的文字编辑器。最初是为macOS构建的，使用Cocoa进行用户界面。第三方开发者还提供了其他操作系统的前端。

目标包括

• 惊人的性能。所有编辑操作应能在16ms内提交和绘制。编辑器不应让您等待任何事情。

• 美观。编辑器应与现代桌面很好地搭配，不应看起来像80年代或90年代的复古产品。文本绘制应使用最佳技术（Mac上的Core Text，Windows上的DirectWrite等），并完全支持Unicode。

• 可靠性。崩溃、挂起或丢失工作不应发生。

• 开发者友好性。应易于自定义xi编辑器，无论是通过添加插件还是对核心进行修改。

了解更多，请参阅Xi的创造者Raph Levien在Recurse Center Localhost讲座中的讲解。

屏幕截图

入门

此存储库仅包含核心。您还需要以下列表中的一个前端。

构建核心

Xi-editor针对'recent stable Rust'。我们建议通过rustup安装。当前最低支持的版本是1.40。

从本仓库的根目录构建xi-editor核心

> cd rust
> cargo build

前端

以下是一些处于不同开发阶段的前端

• xi-mac，官方的macOS前端。

• xi-gtk，一个GTK+前端。

• xi-term，一个文本UI。

• xi-electron，基于Web技术的跨平台前端。

• Tau，用Rust编写的GTK+前端。从https://github.com/bvinc/gxi分叉，该分支已被放弃。

• xi-win，用Rust编写的实验性Windows前端。

• kod，用Golang编写的终端前端。

• xi-qt，一个Qt前端。

• vixi，用Rust编写的类似Vim的前端。

以下目前处于非活动状态，基于前端协议的早期版本，但可能可以复兴

• xi_glium，一个基于Rust的实验性GL前端。

• XiEditorVS2015，C#。

• xi-android，一个Android前端。

有关协议的笔记（此时还不能称之为文档）可以在frontend.md找到。如果您正在开发前端，欢迎将PR发送到上述列表中。

设计决策

以下是一些设计决策及其背后的动机，为什么它们应该有助于实现上述目标

• 前端和后端模块的分离。前端负责展示用户界面和绘制满屏文本。后端（也称为“核心”）持有文件缓冲区，并负责所有潜在的昂贵编辑操作。

• 原生UI。跨平台UI工具包从不完全符合预期。构建UI的最佳技术是平台的原生框架。在Mac上，那就是Cocoa。

• Rust。后端需要非常高效。特别是，它应该使用的内存比正在编辑的缓冲区稍多。这种性能在C++中是可能的，但Rust提供了一种更可靠、许多方面都更高级的编程平台。

• 持久的绳子数据结构。持久绳子对于非常大的文件也很高效。此外，它们向客户端提供了一个简单的接口——从概念上讲，它们是一系列字符的序列，就像字符串一样，客户端无需了解任何内部结构。

• 异步操作。编辑器绝不应该阻止用户完成工作。例如，自动保存将启动一个线程，该线程带有当前编辑器缓冲区的快照（持久绳子是写时复制的，因此此操作几乎免费），然后可以在其空闲时将数据写入磁盘，同时缓冲区仍然完全可编辑。

• 插件而非脚本。大多数文本编辑器都有一个用于扩展功能的关联脚本语言。然而，这些语言通常既复杂又弱。xi编辑器将通过管道与插件通信，允许它们用任何语言编写，并使其更容易与版本控制、更深入的代码分析等系统集成。

• JSON协议。前端/后端通信，以及后端与插件之间的通信都基于简单的JSON消息。我考虑过二进制格式，但实际上性能的提升几乎可以忽略不计。使用JSON可以显著降低开发插件的摩擦，因为它对于大多数现代语言都是现成的，而且对于其他语言也有大量的库可用。

当前状态

这仍然是一个处于早期阶段的项目。Mac版本具有基本的编辑功能（它被用来编写这个README），但看起来非常简陋，并且还缺少自动缩进等基本功能。目前，预计其主要社区将是那些对在文本编辑器上修改感兴趣的开发者。

作者

xi-editor项目由Raph Levien发起，但此后已收到许多其他人的贡献。有关详细信息，请参阅AUTHORS文件。

许可证

此项目受Apache 2 许可证的约束。

贡献

我们乐意通过GitHub拉取请求接受贡献。请参阅CONTRIBUTING.md以获取更多详细信息。

如果您有兴趣贡献，但不确定从哪里开始，在https://xi.zulipchat.com上的#xi-editor通道有一个活跃的Zulip频道。还有irc.mozilla.org上的#xi频道。最后，还有一个/r/xi_editor的subreddit。

lib.rs:

通用RPC处理（用于前端和插件通信）。

RPC协议基于JSON-RPC，但有所修改。与JSON-RPC 2.0不同，请求和通知允许在两个方向上进行，而不是强制客户端和服务器角色。此外，不支持批量形式。

由于这些更改使协议不完全符合规范，因此从请求和响应对象中省略了"jsonrpc"成员。