一篇关于在终端显示大号 emoji 的文章引发讨论。作者发现古老的 VT100 DECDHL 控制序列能将字符分成上下两半显示，可用于“合成”大 emoji。评论区则聚焦于 emoji 在终端中的视觉干扰、技术难题（如宽度计算）以及不同用户对 emoji 的接受度。
古老的终端技巧：DECDHL 与大号 Emoji
文章探讨了在终端中显示大号 emoji 的方法，追溯到 1978 年的 VT100 终端。通过使用 DECDHL 控制序列，可以将一个字符分成上下两半，分别显示在连续的两行上，从而实现大号文字效果。这种技术并非真正放大字体，而是利用字符分割和多行显示来模拟。
作者提供了一个简单的 printf 命令示例，让读者可以在自己的终端上测试这种效果。更有趣的是，这种方法允许将不同 emoji 的上半部分和下半部分组合，创造出独特的“合成”emoji。这种方法的优点在于，如果终端不支持，它会优雅地降级，只显示重复的文本。然而，并非所有现代终端都能同时支持这种老技术和完整的 Unicode emoji 显示。文章也提及了像 Kitty 这样的新终端提供了更现代的文本大小控制方式。
终端中的 Emoji 之争：视觉、技术与偏好
评论区对在终端中使用 emoji 展开了热烈讨论。一个主要观点是，emoji 颜色鲜艳、细节复杂，视觉层级过高，在以文本为主的终端环境中容易分散注意力，尤其是在大量输出或使用终端复用器时。有人将其比作 LLM 倾向于过度使用 emoji，反而淹没重要信息。
然而，也有人认为这可能与年龄有关，年轻一代更习惯将 emoji 作为视觉索引，认为它们能有效传达信息，例如在命令行提示符中用 emoji 表示 Git 分支状态可以节省空间。针对视觉干扰问题，评论者建议终端可以支持单色 emoji 字体，或工具应提供开关让用户选择是否显示 emoji。
讨论还深入到终端处理 emoji 的技术挑战，主要是 Unicode 的“字素簇”（grapheme clusters）和“码点”（codepoints）与终端显示单元格宽度不匹配的问题。一个 emoji 可能由多个码点组成，但终端的 wcwidth() 函数可能无法准确判断其实际显示宽度，导致光标错位等 bug，这给终端应用（如 readline）处理输入带来了困难，且 Unicode 标准的不断更新增加了维护负担。
文章介绍了 Starship，一个快速、高度可定制的跨 shell 命令行提示符工具。它以 Rust 编写，支持多种 shell 和操作系统，并可通过 Nerd Font 显示图标。评论区围绕“理想提示符”展开辩论，讨论了极简主义与信息最大化两种设计哲学，以及在提示符中显示时间等信息的价值。
Starship：打造你的理想命令行提示符
Starship 是一个旨在提供极简、超快且高度可定制命令行提示符的工具，目标是让用户在任何 shell 和操作系统上都能获得一致且高效的体验。
文章强调了 Starship 的几个核心优势：首先是广泛的兼容性，支持 Bash, Zsh, Fish, PowerShell 等多种主流 shell，方便用户在不同环境间切换。其次是卓越的性能，得益于其 Rust 语言的实现，Starship 运行速度快，不会影响终端响应。最后是强大的定制能力，用户可以精确配置提示符显示哪些信息以及显示格式，无论是追求只显示当前目录的极简风格，还是需要包含 Git 分支状态、编程语言版本、云环境等详细信息的“信息面板”，Starship 都能满足需求。安装过程通常也很简单，只需下载二进制文件并在 shell 配置文件中添加一行初始化脚本即可，它还支持 Nerd Font 来显示丰富的图标。
命令行提示符哲学：极简还是信息爆炸？
评论区对“理想的命令行提示符”展开了热烈讨论，反映了开发者们不同的工作习惯和偏好。一部分人是极简主义的拥护者，他们认为提示符只需显示当前目录，其他信息（如 Git 状态、当前用户等）应在需要时通过单独命令（如 git status, pwd）查看。他们认为这种方式能在任何机器上保持一致性，避免过度依赖定制配置。
另一部分人则倾向于“信息最大化”，喜欢在提示符中一眼看到各种上下文信息，例如 Git 分支状态（是否有未提交/未推送）、当前激活的编程语言版本或虚拟环境、甚至当前的 AWS 账号或 Kubernetes 集群。他们认为这能有效提供上下文，帮助防止在错误的环境下执行命令。关于是否在提示符中显示命令