程序员因对现有文本编辑器不满，决定自己开发并长期使用。他认为玩具软件和真实世界应用存在差距，之前使用的编辑器虽轻量高效，但仍有不足，于是动手打造符合自己需求的编辑器。

打造我的专属文本编辑器：从零到日常使用的全记录

缘起：对现有编辑器的不满

作为一名程序员，我长期使用Howl编辑器已近十年。虽然它轻量高效，但存在几个致命缺陷： 1. 项目已停止维护多年，我只能维护自己的分支 2. 项目范围文件搜索性能堪忧 3. 纯GUI设计无法通过SSH流畅使用 4. 缺乏真正的集成终端

尝试过Helix、VS Code等十余款编辑器后，始终找不到那种"得心应手"的感觉。最终，我决定自己打造一款完全符合需求的编辑器。

开发历程

初期策略： - 仅实现我个人需要的功能，所有偏好硬编码实现 - 暂时采用简单的字符串缓冲区 - 有限支持Unicode和语法高亮

关键转折点： 1. 强制用自制编辑器替代nano进行日常编辑 2. 即时记录所有遇到的问题 3. 对影响体验的问题立即修复

这些实践使我的开发效率从每月1小时提升到每周数小时，最近6个月就贡献了约1万行代码。

核心技术挑战

光标控制： - 实现组合键操作需要处理复杂的状态逻辑 - 高阶操作应基于原始操作构建 - 撤销/重做时需要将相关操作分组

文件浏览器： - 借鉴Howl的优秀设计： - 实时模糊过滤 - 支持路径快捷跳转（如~/） - 文件预览功能 - 简化搜索算法，仅需三个标准即可实现95%准确率

正则表达式引擎： - 自主实现支持上下文敏感的正则引擎 - 经过多次优化： - AST优化器 - 公共前缀检测 - 线程代码VM实现 - 尾调用优化 - 最终实现5万行Rust代码10毫秒内完成高亮

语法高亮： - 采用按需分块缓存机制 - 编辑时仅使受影响区块失效 - 多窗口查看同一文件时仍能高效工作

项目搜索： - 基于.git目录自动识别项目根 - 多线程工作窃取算法 - 结果按路径相关性排序 - 现代SSD+优化正则使搜索几乎即时完成

终端模拟： - 集成alacritty_terminal实现完整终端支持 - 编辑器本身可替代screen/tmux使用

渲染优化： - 双缓冲终端屏幕 - 仅重绘变更的单元格 - 实际性能优于直接cat大文件

收获与启示

1. 完美契合个人需求：完全按照我的工作流定制
2. 技术深度掌握：深入理解了正则、ANSI、伪终端等关键技术
3. 长期生产力提升：减少工具对抗，专注思考性工作
4. 重拾编程乐趣：在解决具体问题时重新找到编程的纯粹快乐

这段旅程证明：打造自己的工具绝非徒劳。它不仅能创造完美适配的工具，更能重新点燃对编程的热爱。我鼓励每个有动力的工程师都尝试创造属于自己的工具——不必是编辑器，但请享受挑战的过程，别把困难部分都推给统计黑箱。在奋斗中自有乐趣。

（配图为编辑器实际工作截图，显示正在编辑本文档）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持自制文本编辑器的观点

1. 个人价值与学习意义

   • "I use my own text editor... I’m still surprised by the value we get from home grown solutions" (codazoda)
   • "Building your own editor... teaches you far more about software design" (priowise)

2. 性能与定制化优势

   • "All this running on a pentium 120... felt a thousands times faster than today’s vscode" (whynotmaybe)
   • "Good old style editor... super snappy. I can’t bear the latency of vscode" (greatgib)

对现有编辑器的偏好

1. 经典编辑器的持久性

   • "There’s a reason Emacs and vi have been around for decades. They’re good" (kleiba)
   • "I am now at home with Helix and Flow Control" (osmsucks)

2. 模块化改进需求

   • "I want to piece together an editor from modular task specific executables" (willrshansen)
   • "Probably similar to how LSPs are already separated" (willrshansen)

技术挑战与反思

1. 开发难度

   • "Cursor manipulation is difficult... the logic required is not fun to write" (piker)
   • "A string buffer is quick to implement but you will hit a wall" (mudkipdev)

2. 怀旧与局限

   • "Fond memory of when I wrote an editor in the 90’s... But vscode can edit multiple files" (whynotmaybe)
   • "I, too, mourn the death of Howl. It was a quirky yet comfortable editor" (osmsucks)

其他观点

• 特定推荐：推荐Kate编辑器（"native app, not electron... simple and efficient" - greatgib）和Codex（"90% of the way there... incredibly exciting" - postalcoder）
• 幽默/质疑： "I smell money burning" (givemeethekeys) 和 "Should make my own... interesting project" (abktowa)

（注：所有评论均无评分，因此未体现认可度差异）