文章探讨了终端设计的现状与未来，指出当前终端内部结构混乱，许多设计源于上世纪80年代的决定且难以改变。作者提出终端由四个核心部分组成：终端模拟器、伪终端（PTY）、shell和进程组，并强调重新设计基础设施需要像Clojure创始人那样进行整体革新，而非在旧系统上堆叠修补。

未来终端的构想

终端的基本构成

终端在高层面上可分为四个部分： 1. 终端模拟器：负责在图形界面上渲染网格状结构。 2. 伪终端（PTY）：连接终端模拟器与接收输入的"进程组"，是内核中的一种状态。 3. Shell：作为进程组的领导者，负责解析输入、生成进程并充当事件循环（如bash）。 4. 由Shell生成的程序：与上述部分交互以实现输入输出。

现有终端的局限性

当前终端系统存在诸多限制，主要源于上世纪80年代的设计决策难以更改。这些限制包括： - 输入不仅包含文本，还包括发送给运行进程的信号（由PTY负责转换按键为信号）。 - 输出是ANSI转义序列流，用于终端模拟器显示丰富格式。

改进方向：Jupyter Notebook的启示

Jupyter Notebook展示了传统VT100模拟器无法实现的功能： - 高保真图像渲染 - "重新运行"按钮（替换而非追加输出） - 源代码和输出的可重写视图 - 内置编辑器（支持语法高亮、标签页等）

但直接将其应用于Shell会遇到问题： - Shell无法逐字符接收命令（影响自动补全等功能） - 难以处理长时间运行进程（如vi或top） - "重新运行"可能破坏系统状态 - 撤销/重做功能缺失

解决方案的关键技术

1. Shell集成：

   • 如Warp终端通过自定义DCS实现终端与Shell的深度集成，能精美渲染命令输入输出。
   • iTerm2通过OSC 133转义代码实现类似功能，支持命令导航等特性。

2. 长时间运行进程管理：

   • 交互：通过Jupyter的交互式输出功能实现双向通信。
   • 挂起：借鉴IntelliJ的后台任务可视化方式显示挂起进程。
   • 断开连接：
     • Tmux/Zellij方案：在终端模拟器与程序间插入额外终端模拟器。
     • Mosh方案：作为SSH替代品，通过状态机实现网络中断后重连。
     • 轻量级方案（如alden/shpool）：仅处理会话分离/恢复，不包含终端模拟器。

3. 重新运行与撤销/重做：

   • 借鉴Pluto.jl的数据流追踪技术，将进程视为输入（文件系统、环境变量等）的纯函数。
   • 通过沙盒化进程、跟踪所有I/O实现正交持久性。

分阶段实施路径

1. 事务语义：

   • 从CLI层入手，实现终端操作的事务性（开始/回滚/提交）。

2. 持久会话：

   • 通过客户端/服务器模型实现PTY持久化。
   • 服务器保存输入输出实现"原生"回滚。
   • 结合Eternal TCP优化网络连接。

3. 结构化RPC：

   • 通过元数据标记I/O，构建终端会话的结构化日志。
   • 支持会话回放、转换等高级功能。

4. Jupyter式前端：

   • 最后改造终端模拟器，整合所有功能提供完善UI。

展望

这一构想虽雄心勃勃（可能需要十年实现），但通过渐进式改进，每个阶段都能提供切实的价值。最终目标是打造一个兼具强大功能与优雅设计的现代化终端系统。

（注：原文中的图片引用和部分技术细节链接已省略，保留了核心逻辑框架）

以下是评论内容的总结：

1. 终端未来发展方向

• 浏览器化观点
  "The terminal of the future is called a web browser." (评论1)
  "But just showing a browser like Jupyter would be very useful... can handle JS heavy webpages unlike curl" (评论16)

• 反对过度复杂化
  "Complexity leads to instability. Terminals has to be nimble and not clumsy behemoths like web browsers." (评论4)
  "The last thing a command-line terminal needs is a Jupyter Notebook-like UI." (评论13)

2. 现有工具的局限性

• 功能缺失问题
  "gave up on Warp because it doesn’t support standard or custom command completions" (评论2)
  "iTerm2 already does this... can upgrade without interrupting sessions" (评论9)

• 替代方案存在但未被提及
  "We already have alternatives... Emacs, Acme" (评论7)
  "Any article... that does not mention Arcan feels incomplete" (评论12)

3. 技术改进建议

• 协议增强提案
  "enhanced to provide out-of-band data... like JSON-RPC messages" (评论17)
  "would love for more terminal emulators to support OSC 133" (评论21)

• 兼容性优先
  "Maintaining backwards compatibility is critical... unlike GUIs it's super easy to turn workflow into script" (评论20)
  "stop back-porting new features into vt terms... we get ESC[whatever-the-fuck-i-feel-like]" (评论22)

4. 特定工具评价

• Jupyter Notebook争议
  "Pluto.jl... handles dependencies between code cells is really nice" (评论8)
  "quickly ends up becoming production workload... hard to deploy ops way" (评论23)

• AI融合期待
  "expected to be about 'AI first' terminal" (评论11)
  "future is IM App... people and machines will chat" (评论24)

5. 历史与设计哲学

• 保守派观点
  "design decisions made 40 years ago... why we still use it today" (评论13)
  "VT100 features beyond UTF-8 have not caught on" (评论5)

• 革新派观点
  "Great thought provoking article!... typing commands feels primitive" (评论14)
  "introduces new protocol for TUI... better interactions" (评论15)

总结显示评论围绕终端发展方向产生明显分歧：一方主张通过浏览器/Jupyter等现代技术革新，另一方强调保持简洁性和兼容性。现有工具（如iTerm2/Emacs）的功能和替代方案（如Arcan）被多次提及，Jupyter Notebook的评价呈现两极分化。技术改进建议集中在协议增强（如OSC 133/JSON-RPC）和兼容性维护上。