编程与软件工程ecc-comp.blogspot.com
各类文本编辑器如何管理文本数据（2015）
A Brief Glance at How Various Text Editors Manage Their Textual Data (2015)
2016 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2015 年的博文简要考察了多种文本编辑器如何在内部表示和管理文本数据，比较不同结构在插入、删除、大文件编辑等场景下的取舍。文章因把编辑器核心数据结构讲得清晰而反复被 Hacker News 讨论，评论区还补充了 piece table、sam 的远程编辑设计等经典实现。
为什么经久不衰：它用简短篇幅揭开日常编辑器背后的核心数据结构，相关讨论又补充了多种经典实现，今天仍是理解编辑器设计的良好入口。
HN 评论精选
补充 piece table 结构，并指出它对持久撤销/重做的优势。
文章漏掉了“piece chain”（即 piece table）这一重要但常被忽视的结构。虽然流行编辑器中不常见，但 MS Word 据称内部使用过它，AbiWord、vis 以及 Oberon OS 的编辑器也用了。它的一大优势是能轻松支持快速、无限且持久的撤销/重做。
akavel查看英文原文
The article is missing one of the important but commonly overlooked structures: a "piece chain" [1] (aka "piece table"). Not easy to find editors using it, especially among the popular ones, but: - from what I've read somewhere, MS Word was/is (?) using it internally [http://1017.songtrellisopml.com/whatsBeenWroughtUsingPieceTables, ] - AbiWord [1] - [1]: http://www.catch22.net/tuts/piece-chains - https://github.com/martanne/vis - the text editor of the Oberon OS used it [1] One of its most intevesting advantages is that it trivially supports fast unlimited and persistent undo/redo
sam 把编辑核心与界面分离，samterm 仅加载可见文本以支持慢速远程大文件编辑。
sam 实现的一个有趣之处是它实际有两种文本表示。文章讨论的是主 sam 进程中的部分；samterm 进程里还有另一种数据结构，只保存已经显示在 samterm GUI 中的文件片段。这意味着你可以让 sam 和 samterm 运行在慢速链路两端，仍能编辑超大文件。远程 sam 进程把文件载入文章描述的结构；samterm 只通过慢链路加载绘制当前窗口所需的那段文本。随着你在文件中移动，samterm 会逐步填充所需文本。samterm 端的数据结构叫 Rasp：一个带洞的文件。
mhw查看英文原文
One interesting aspect of the implementation of sam is that there are actually two different text representations. What's discussed here is the part in the main sam process, but there's another data structure in the samterm process that contains only those sections of the file that have actually been displayed in the samterm GUI. This meant that you could run sam and samterm on opposite ends of a slow link and still be able to edit very large files. The remote sam process loads the file into the data structure described in the original article. samterm only loaded (over the slow link) the section of the file needed to draw a window containing the part of the text the user was looking at. As you moved around the file samterm would fill in parts of the data structure with the text you needed to see. The data structure used on the samterm end is called a Rasp: a file with holes. See https://plan9port.googlesource.com/plan9/+/refs/heads/master/src/cmd/samterm/rasp.c
推荐一篇系统讲解文本序列数据结构的经典论文。
如果你对此感兴趣，Charles Crowley 的《Data Structures for Text Sequences》是一篇很好的研读论文。
flyingmutant查看英文原文
If you are interested in this, [Data Structures for Text Sequences](https://www.cs.unm.edu/~crowley/papers/sds.pdf) by Charles Crowley is an excellent paper to study.
现代硬件下简单缓冲区已足够快，复杂数据结构未必值得，编辑器性能问题常另有原因。
这很高效，但代价是 Vi 处理超大文件时会变慢，因为它必须遍历更大的线性数组。换个角度看“更大”：现代 CPU 遍历和复制内存的速度超过 10GB/s。因此我一直觉得，追求更“高效”（也更复杂）的文本编辑器数据结构的论点有些站不住脚——即使每次插入都要移动数 MB 数据（简单无间隙缓冲区就是这样），计算机实际上快到用户根本看不出区别；每次击键 1ms 和 1us 的延迟，对用户来说几乎无法区分。这并不是说我反对优化；恰恰相反，但 80 年代到 90 年代初那些使用同样“单缓冲区”范式的 DOS 小编辑器，甚至 PC 上的语法高亮 IDE，在内存带宽远低于今天的机器上也很流行且少有速度抱怨，这说明更“聪明”的数据结构带来的复杂性可能并不值得。……然而我们仍能做出光标闪烁就占满一个 CPU 核心的编辑器。
userbinator查看英文原文
This is very efficient, but the consequence is Vi will become slow when working with huge files, because it has to traverse through a bigger linear array To put "bigger" into perspective, a modern CPU can traverse and copy memory at over 10GB/s. This is why I've always found the argument for more "efficient" (and complex) text editor data structures a bit tenuous --- even if you have to move MBs of data with every insertion (as happens with a simple gapless buffer), computers truly are so fast that it wouldn't look any different to the end-user; a 1ms and 1us delay upon each keystroke is, to the user, practically indistinguishable. That's not to say I'm one of those who preach against "premature optimisation" and don't care about efficiency; far from that, in fact, but the popularity of and lack of speed-related complaints against the small DOS text editors and even syntax-highlighting IDEs on PCs in the 80s through early 90s which used the same "one buffer" paradigm, on machines with a fraction of the memory bandwidth of those today, suggest that the complexity of more "clever" data structures may not be worth it. ...and yet we somehow still manage to make editors that peg a single CPU core just blinking a cursor.[1] [1] https://news.ycombinator.com/item?id=13940014
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选