Define the console glyph vocabulary: replace kaomoji with a width-aware icon set
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- csharp
- Lĩnh vực
- build-system, cli, tooling
Hướng nghiên cứu
Bắt đầu với src/Fallout.Build/Host.cs, đặc biệt là WriteTargetOutcome, sau đó kiểm tra src/Fallout.Build/Execution/BuildManager.cs và src/Fallout.Build/Logging.cs. Đọc phần di chuyển sang Spectre trong #391 trước khi chọn thuật ngữ và cách tiếp cận về capability. Được xem là hoàn tất khi bộ glyph có xét đến độ rộng đã được ghi lại, ASCII fallback, hành vi NO_COLOR và đầu ra trạng thái không màu đáp ứng các tiêu chí chấp nhận được liệt kê.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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_COLORis 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.
- Ngôn ngữ chính
- C#
- Star
- 179
- Fork
- 25
- Merge trung bình
- 1 ngày 17 giờ
- Pull request đã merge (30 ngày)
- 14
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Fallout-build/Fallout
-
bug needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Fallout-build/Fallout#729 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Fallout-build/Fallout#708 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
.\build.ps1 in its current state isn't capable for :add-package commandCó thể đã có người làm @ITaluone đã nhận 58 ngày trước. Đang mởbug needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Fallout-build/Fallout#670 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
CD enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Fallout-build/Fallout#649 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Fallout-build/Fallout#630 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của Fallout-build/Fallout
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Sample solution restore fails with NU1109 (Microsoft.Extensions.Logging.Abstractions downgrade)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
ardalis/CleanArchitecture#1150 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
reacher-z/Awesome-REA#3585 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
resend/resend-dotnet#174 ·
-
Add Vigil (BofStudios/vigil)Đang mởarea:data coverage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
reacher-z/Awesome-CUA#5039 ·
Maintainer thường phản hồi trong vòng 19 ngày