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

オープン
  • 何か問題がありますか？
#557 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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 への移行を読んでください。文書化された幅対応のグリフセット、ASCII フォールバック、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時間
マージ済み PR（30日）
14

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Fallout-build/Fallout のほかの issue

Fallout-build/Fallout の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。