C++ 编辑器核心缓冲区类型和语法突出显示

我一直在思考如何使编辑器的核心功能与vim兼容，类似于yzis

最大的问题是使用哪种缓冲区类型

要求如下：

• 实现快速语法高亮显示的可能性，正则表达式在上面
• 在一个文件中实现多个语法高亮显示的可能性。类似于textmates范围
• 删除插入项上的正确移动标记。以便在列中进行适当调整。与vim不同
• 处理并突出显示至少100 mb的文件，而不会出现太大的问题和内存开销

可能的缓冲区类型：

• 间隙缓冲器
• 基于行的编辑

我了解到，在较长的运行时间内，间隙缓冲区会导致相当大的内存碎片。另外，emacs语法突出显示引擎速度非常慢（不知道为什么，可能与缓冲区类型无关）

因此，问题是：

对于快速编程编辑器，哪种缓冲区类型最好

什么是快速/完整的正则表达式引擎？（这可能包括下一点）。TextMate使用oniguruma，这是明智的选择吗

什么是快速语法突出显示引擎

关于标记和语法突出显示。emacs覆盖层是如何工作的，它们会有帮助吗

谢谢，

---

Reza

您可以使用闪烁类。您的视图可以从闪烁视图派生，它提供语法高亮显示

一个好的文本编辑器应该对程序员可能做的各种工作都很有用，包括打开有时可能是几GB大小的文件。因此，我不推荐在RAM中缓冲所有内容的思维方式

我建议设置一个表示文件的切片搜索树，其中单个切片可能是：

对磁盘上实际文件中字节范围的引用，或

对已编辑“页面”的引用

打开文件时，首先在树中插入一个项目，这只是表示整个文件的一个范围，例如，对于10 MiB文件：

std::map<size_t, slice_info> slices;
slices[0].size = 10*1024*1024;

您可以将内存映射文件用于只读缓冲区（源文件）和复制的可编辑缓冲区（后者将放置在临时目录中）。这还允许在编辑器崩溃时进行恢复

使用固定大小的页面将大大减少内存堆的碎片，因为所有块的大小都相同，插入文本永远不需要移动超过4kib的数据

这是一个简单的描述，以给出总体思路，而不涉及太多的细节。真正的实现很可能需要更加复杂，例如，允许页面中有可变数量的数据来处理溢出的页面，并将许多小片段合并在一起，以便在一个大文件上运行正则表达式替换不会创建太多的小缓冲区。可能需要对树中同时应具有的切片数量进行限制，但关键是，当开始插入某个位置时，应确保使用的切片不是太大

对于regex，我认为只要整个编辑器在运行时不挂起，性能就不是什么问题。尝试一下，它很可能足够快满足您的需要，而且它也足够通用，可以插入您需要的任何缓冲策略

这同样适用于语法高亮显示，如果您在后台运行它，则不会在用户键入时对其造成太大干扰。在这里，您可以使用切片方法为您带来好处：

• 每个片段都可以有一个互斥锁，可以在编辑操作期间锁定，从而允许在后台线程中运行语法高亮显示或“intellisense”类型分析
• 您可以存储语法高亮显示引擎的状态，以便无论何时在切片中进行编辑，都可以从该切片的开头而不是从文件的开头重新启动语法高亮显示

---

我不知道有任何独立的语法突出显示引擎，但它们通常基于正则表达式替换（例如，请参阅vim中的语法突出显示文件）。

祝您好运，这是一项难以想象的艰巨任务。记住，如果你做了一个功能到功能的Vim克隆，你可能最终会被送进精神病院最大的问题是你为什么要这么做？vim拥有30年的知识资本投资，你能做些什么来与之竞争？如果你想要一个不同类型的编辑器，那是一回事，但是重做vim注定会失败。（对不起，讨厌成为一个消极的nancy）关于这一点我可以写很多，但归根结底是Ali和Whaledawg已经说过了。不要这样做。如果你已经要求做这件事，你是做不到的。不是真的，vim也有自己的问题。虽然阿里的评论很有趣，但其余的几乎没有。这有点像是在问：“为什么要发明新车，凯迪拉克埃尔多拉多还开着，不是吗？”嗨，弗洛丁，回答得很好。我从来没有想过在后台运行regex（还有语法hl，除非我实现lexer）。然而，最后，您似乎在描述工件表方法。我担心的是，如果你有很多未限制的工作，正则表达式将变得难以管理？

size_t const PAGE_SIZE = 4*1024;
slices[0].size = 5*1024*1024;
slices[5*1024*1024].size = PAGE_SIZE;
slices[5*1024*1024].buffer = create_buffer(file, 5*1024*1024, PAGE_SIZE);
slices[5*1024*1024 + PAGE_SIZE].size = 5*1024*1024 - PAGE_SIZE