最新

danterm最初是一个围绕libghostty的小型AppKit封装，以便我能够实现垂直标签页。<p>代码库：<a href="https:&#x2F;&#x2F;github.com&#x2F;danneu&#x2F;danterm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;danneu&#x2F;danterm</a><p>大约3-4周前，我决定用我自己的Swift终端引擎实现替代libghostty，整个项目完全使用Swift，没有第三方依赖——仅使用了Apple的swift-collection来实现双端队列。<p>我从一个简单的正确性实现开始，该实现通过了第三方测试，然后逐步优化到今天的版本，增加了按需扩展的紧凑字节区域用于滚动回溯。<p>结果是，这个应用程序的大小为8 MB，在打开10个空标签页时占用52 MB，当这些标签页每个填充1万行时，大小仅增长到250 MB。（kitty: 240 -&gt; 790 MB，ghostty 1.3: 780 -&gt; 1400 MB）。它还具有最佳的pty吞吐量，经过kitty的`kitten __benchmark__ --render`测量。<p>也许最有趣的是，这个项目是我最新的实验，旨在如何利用严格的方法通过大型语言模型（LLMs）来自动化高质量软件。我使用了ADR、文档/研究系统、计划的审查/修订周期以及多次工作流程来偿还技术债务并寻找代码改进机会。<p>例如：<a href="https:&#x2F;&#x2F;github.com&#x2F;danneu&#x2F;danterm&#x2F;blob&#x2F;749942ffa1198f520c8b752c7af6caab7ae7ce0b&#x2F;docs&#x2F;scratch&#x2F;2026-08-26-improvement-audit.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;danneu&#x2F;danterm&#x2F;blob&#x2F;749942ffa1198f520c8b7...</a><p>这个项目让我更加确信，大多数软件——最终所有软件——都可以通过一个人类“品味引导者”完全自动化。<p>它还具有一些有趣的功能，例如：<p>- 一个`danterm &lt;command&gt;`命令行界面<p>- 可回放的pty飞行记录仪（`danterm tape`）<p>- 常规功能，如标签、窗格、主题、搜索和恢复系统，允许您关闭danterm后重新打开，并从磁盘读取其先前状态。甚至还有一个花哨的待办事项系统（按窗格和标签分类）。<p>- 一个由shell/agent集成驱动的语义模型，您可以通知danterm诸如“命令已启动（vim foo.sh）”和“代理等待（claude code）”等信息。这似乎比试图巧妙地从pty流中确定会话状态要合理得多。<p>- 一个伴随的iPhone应用程序，让我可以通过Tailscale远程控制danterm<p>- 一个可重用的Swift终端引擎，可以在Linux上编译（为了好玩，我开始了一个gtk4前端）<p>总之，我希望这对您有趣。这是一个耗费大量精力的项目，也是我日常使用的终端。

上下文长度曾经是新模型的一个重要指标。我几乎不再听到关于它的讨论，但我无法想象它在实际性能中不再发挥重要作用。<p>这真的不再是一个瓶颈了吗，还是说它现在只是被包含在主要基准数字中？