Define the console glyph vocabulary: replace kaomoji with a width-aware icon set

未关闭
  • 哪里不对？
#557 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
csharp
领域
build-system, cli, tooling

调研方向

从 src/Fallout.Build/Host.cs 开始，尤其是 WriteTargetOutcome，然后检查 src/Fallout.Build/Execution/BuildManager.cs 和 src/Fallout.Build/Logging.cs。在选择术语和 capability 方法之前，先阅读 #391 中关于迁移到 Spectre 的内容。已完成的标准是：有文档说明的宽度感知 glyph 集、ASCII fallback、NO_COLOR 行为以及非彩色状态输出满足列出的验收标准。

由索引模型根据 Issue 内容生成。

描述

enhancement
Problem

The inherited NUKE glyph vocabulary is arbitrary. The build outcome line ends in kaomoji (src/Fallout.Build/Host.cs:176-179):

Build succeeded on 26/07/2026 22:49:03. ＼（＾ᴗ＾）／
Build failed on 26/07/2026 22:49:45. (╯°□°）╯︵ ┻━┻

Elsewhere: ☢ in the logo tagline (deliberate, keep), » as a selection marker, ¬ as a confirmation marker (#555). Target status in the summary table is carried by colour alone — green Succeeded, yellow NotRun, red Failed — with no glyph.

There is no vocabulary: no rule for which glyph means what, no fallback for terminals that cannot render one, and no width handling.

Outcome

A defined, documented icon set where each glyph is self-explaining, renders at a known width, and degrades to ASCII when the terminal cannot show it. Status is legible without colour.

Acceptance criteria
  • A single internal source of truth maps semantic states (succeeded / failed / skipped / not-run / aborted / warning / running) to glyphs
  • Every glyph has an ASCII fallback, selected by a capability probe rather than assumed
  • Glyph rendering goes through display-width measurement, not string.Length
  • Kaomoji removed from the build outcome line
  • NO_COLOR is honoured, and status stays distinguishable with colour off
  • The vocabulary is documented so tool wrappers and plugins use the same glyphs
Design constraints

1. Column alignment breaks twice over. Host.WriteTargetOutcome pads with PadRight/PadLeft over string.Length — UTF-16 code units. Emoji break both halves of that assumption:

Glyph Code units Display cells
✅ U+2705 1 2
⚠️ U+26A0 U+FE0F 2 2
✔ U+2714 1 1
☢ U+2622 1 1

PadRight over-pads narrow glyphs and under-pads wide ones. This is why the item belongs to the Spectre migration: Spectre.Console measures display width and owns the table layout. Doing it on the current PadRight code means hand-rolling a width table.

2. Terminal capability is a matrix, not a boolean. Console.OutputEncoding = Encoding.UTF8 is already set (src/Fallout.Build/Execution/BuildManager.cs:39), so encoding is fine — but legacy conhost with a raster font renders emoji as boxes. The existing capability check is a single bad sniff (TERM starts with xterm, src/Fallout.Build/Logging.cs:21), which reports no ANSI support on Windows Terminal. A real probe is a prerequisite, not an afterthought.

3. Emoji do not take colour. Status is conveyed by ANSI colour today. Presentation-form emoji ignore SGR, so the glyph column and the colour scheme have to be designed together. Treat the glyph as the accessibility win — colour-blind readers, NO_COLOR, piped logs, CI log viewers — rather than decoration.

4. Two glyph classes, different rules. Narrow single-cell symbols (✔ ✖ ✱ » ‣) can sit inside padded columns and take colour. Wide emoji (✅ ❌ ⚠️ ⏭️) cannot sit in a padded column without width-aware measurement, and are best kept to non-tabular lines (the outcome line, block headers).

Open questions
  • Narrow symbols everywhere, or wide emoji on non-tabular lines and narrow symbols in the table?
  • Is the glyph additive to the status word, or does it replace it?
  • Does the CI-host path get glyphs at all, or do GitHub Actions / TeamCity annotations carry that already?
Notes

Sub-issue of #391 — depends on Spectre owning the table layout and display-width measurement. The ¬ confirmation marker (#555) is fixed independently as a plain bug; this issue defines the vocabulary it should eventually draw from.

主要语言
C#
星标
179
派生
25
平均合并
1 天 17 小时
30 天内合并 PR
14

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Fallout-build/Fallout 的其他 Issue

查看 Fallout-build/Fallout 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。