编程与软件工程acko.net
TermKit：图形化终端替代品
TermKit - a graphical terminal replacement
2011 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
TermKit 是 Steven Wittens 在 2011 年发布的实验性项目，试图用图形化、富媒体的方式重新设计终端，让命令行输出可以显示图片、图标等丰富内容。文章引发了关于终端与 Unix 哲学是否应该被革新的长期争论，项目后来逐渐停止维护。
为什么经久不衰：它提出了一个至今仍未解决的根本问题：终端的文本流模型是否还适应当代需求，后来 iTerm2、kitty 等终端的图形能力都可视为对这一思路的回应。
HN 评论精选
图形化输出信息密度反而更低，且给数据流统一加类型不现实，增强协议加查看器是更好的路径。
有趣的是，他的 ls 默认输出信息稀疏的图标网格（只显示 10 项还要横向滚动条？），而我用命令行恰恰是为了获得与 GUI 相反的东西——信息密集的文本表格。我同意那位评论者：-r-xr-xr-x 甚至 0555 都远好过“你碰不了这个”（这既没说明谁不能碰，也没说明在哪些方面不能碰）。他的“富显示”其实是贫乏的显示——传达的信息比文本更少。给文件/流数据加类型标注的想法有意思，但不现实——它要求所有工具几乎一夜之间改造以保留头部。而且光保留头部也不够：如果把输出泵到临时文件几毫秒后再读呢？复合文件被截取部分数据呢？想要漂亮图片、语法高亮等，更好的做法是设计一个增强的终端通信协议，加上几个能把数据格式渲染出来的查看程序，而不是改造整个世界给每个数据流都加类型。
barrkel查看英文原文
It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information-dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). His "rich display" is actually a display of poverty - it conveys less information than text. The typing of file / stream data is interesting, but I don't think it's realistic - it requires all tools to change virtually overnight to preserve the headers. And it's not enough just to preserve headers; what if you pump stuff out to a temporary file and read it in a few milliseconds later? What about compound files, with data chopped out of them? If you want pretty pictures, syntax highlighting etc., ISTM better to have an enriched terminal communication protocol along with a couple of viewer programs which can render data formats to it, rather than change the whole world to type every data flow everywhere.
终端有很多可改进之处（状态栏、补全弹窗、拖放、输出折叠），TermKit 的方向值得肯定。
我大约 10 年前有过类似想法，但一直没动手实现。我很惊讶针对这个项目的敌意如此之多——好像终端绝无改进可能似的？但显然可以改进。比如：终端状态栏显示 CWD / git 分支等信息而不占用提示符前的空间，岂不很好？是的，可以用 screen，但那会毁掉滚动条。再比如文件名补全，输入时像浏览器那样弹出候选列表？为什么 ls 出来的文件不能拖放到另一个 Finder 窗口？为什么终端永远与外界隔绝？为什么 mvn install 输出几百万行，结果不能折叠成一行摘要、需要时再展开？这类改进空间很大。我主要的顾虑是单个 WebKit 控件是否是正确路线——最好能在 shell 里嵌入自定义控件（不过这或许也能做到）。所以我认为这是个绝妙的想法。
bernardwilson查看英文原文
I had a similar idea about 10 years ago, but never got around to implementing it. I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!. But clearly it can. For example - wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $? Yep, you can use screen, and that destroys your ability to use the scrollbars. Or, consider filename completion. Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do) ? Why, when I do 'ls', can I not drag & drop one of the files to another finder window? Why is the terminal forever isolated? Why when I run 'mvn install', which generates umpteen bazillion lines of output, can the result not be folded into a single line showing the summary, that I could expand if I wished? There's lots of scope for this kind of thing. My main concern would be whether a single WebKit control is the right way to go - it'd be nice to, for example, embed custom controls within the shell (but this might also be possible). So I think it's an awesome idea.
建议通过 ESC 序列实现可切换的“增强模式”，在 100% 兼容普通终端的前提下渐进式添加富输出。
我喜欢这个！它有根本性的概念缺陷，但拜托，终于有人在重新思考终端了，请继续做下去！我建议的方向是：必须 100% 向后兼容，这不是可选项，否则免谈；同样，重新发明整个 Unix 用户态工具链是个糟糕主意。不如按 Unix 和终端一贯的方式来做：先模拟一个普通终端（xterm/vt10x），增加一个特殊 ESC 序列把终端切换进 TermKit 模式（再一个切回来）。这样我们就有了一个带奖励模式的普通终端。可以提供一个简单的 CLI 包装器来混入“魔法”：比如 cat foo.png | tk_wrap，屏幕上图片就会像文本输出一样嵌入在命令行下方。tk_wrap 是个小包装器，先发出 termkit-esc，再输出 stdin 数据（转成 JSON 元格式），最后发 termkit-end-esc。这就是我想看到的基本架构，从这里开始，上限不可限量。
moe查看英文原文
I love this! It has fundamental conceptional flaws. But hell, finally someone is rethinking the terminal, please continue working on this! Here's the direction I would propose: It must be 100% backwards compatible. This is not optional, anything else is a non-starter. Likewise trying to re-invent the entire unix userspace toolchain is a terrible idea. So why not do it the UNIX-way and how terminals have always done it: Start by emulating a normal terminal (xterm/vt10x). Add support for a special ESC-sequence that switches the terminal into TermKit mode (and another one to switch back). This way we have a normal terminal, with a bonus-mode. A simple cli-wrapper could be provided to mix the "magic" in. E.g. to cat a PNG I would: 'cat foo.png | tk_wrap'. And on the screen that image would magically be embedded below my command line, just like any text output would. tk_wrap would be small wrapper that first emits the termkit-esc, then the stdin-data (converted to the json meta-format), and finally the termkit-end-esc. That's the basic architecture that I'd like to see. And from there, sky's the limit.
老式硬件终端早已具备图形等丰富能力，推动现代终端模拟器支持这些既有标准即可，无需另起炉灶。
终端其实是非常丰富的接口——几十年来它们发展出了许多特性，如 Tektronix 和 ReGIS 图形、排版特性（双倍高度、双倍宽度）、备选字体、多窗口、单声道声音、平滑滚动（可爱但不太有用）以及 Sixel 图形。这些早在终端还是桌上带 CRT 的实体盒子时就已可用，都写在它们的开发者手册里。遗憾的是，这些特性大多不被我们的终端模拟器支持（Apple 的 Terminal 至少支持双倍宽高，xterm 能做 Tektronix 图形），而 ncurses 之类的库让我们无需理解控制序列就能使用其中许多特性（如今大多数终端看起来都像 xterm）。如果能推动对这些特性的支持，我们就有一套已被验证、可能被今天仍在运行的古老软件支持过却从未被正确使用的标准和功能可以依赖。比如如果所有终端都支持 sixel 图形（虽然是个糟糕的标准）或 DRCS（一个还行的标准），我们就不需要为字符图形（Unicode v13 新增了 Teletext 方块图形，4x2 马赛克也快了）或 powerline 符号做字体支持了。
rbanffy查看英文原文
Terminals are actually very rich interfaces - over decades they have developed features, such as Tektronix and ReGIS graphics, type features (double height, double width), alternative fonts, multiple windows, single-voice sounds, smooth scrolling (cute, but not that useful), and Sixel graphics. All these have been available since terminals were actual boxes on our desks with CRTs built-in. All that is described in the developer manuals for them. Unfortunately, most of these features are not supported by our terminal applications (Apple's Terminal supports double width and height, at least, and xterm can do Tektronix graphics) and libraries such as ncurses allow us to write software using many of those features having to understand the control sequences (most terminals today look like xterm). If we could push for support to these features, we'd have an already proven, probably supported by ancient software that we run today but that we never saw as intended, set of standards and functionality we could rely on. If all terminals, for instance, supported sixel graphics (a horrible standard, BTW) or DRCS (a meh one), we wouldn't need font support for character graphics (Unicode v13 has new Teletext block graphics, and 4x2 mosaics will be added soon, and libraries such as VTE implement those without font support) or "powerline" symbols.
历次讨论
同类还值得读
开源应用架构
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编辑精选