Problem
Vimcode bundles a ~13 KB Nerd Font subset at `data/fonts/vimcode-icons.ttf` for GTK. Several `Icon` constants in `src/icons.rs` reference nerd-codepoints that aren't in the subset. When the code calls `Icon::s()` (which returns the nerd variant if nerd fonts are "enabled") and the glyph is missing, Pango silently falls back to system fonts and renders an unrelated character — not the `.fallback` field the `Icon` struct also carries.
Concrete case surfaced while fixing #196: `FIND_IN_SEL.nerd = "\u{eb54}"` (nf-cod-selection) → Pango substitutes a stray `"` because the codepoint isn't in the bundled subset. Worked around in the fix by using `FIND_IN_SEL.fallback` directly for GTK.
Likely affects other icons too — whatever subset generation script was used either missed codepoints or was out of sync with icon additions.
Cross-backend impact
- TUI: fine. Users install a Nerd Font in their terminal (user-supplied); unused codepoints just mean "this glyph won't render" but the terminal's built-in font substitution is usually sensible.
- GTK: the bundled subset is all it has. Missing glyphs → misleading substitutions from system fonts.
- Win-GUI / macOS (future): same risk as GTK unless they bundle a full Nerd Font.
Suggested Fixes (ordered by scope)
- Audit + regenerate bundled subset — walk every `Icon::new(nerd, ...)` in `src/icons.rs`, extract the nerd codepoints, regenerate the subset to include all of them. Mechanical.
- Add a CI check — each time `src/icons.rs` changes, re-generate / re-verify the subset so it stays in sync.
- Move the nerd font preference check into `Icon::s()` per-backend — at the moment it's a global `USE_NERD_FONTS` flag; backends can't individually say "I don't have a glyph for this." Making the glyph-availability check backend-aware is a larger refactor but more correct.
Option 1 is the quick fix; 2+3 are infrastructure.
Files
- `src/icons.rs` — all `Icon::new(nerd, fallback)` constants; audit the nerd codepoints.
- `data/fonts/vimcode-icons.ttf` — bundled subset.
- `build.rs` or a separate script — whatever regenerates the subset (check the repo for a generator).
Priority
Minor visual glitches accumulating. Individually dodgeable via `.fallback` workarounds (as done in #196), but the workaround needs to be applied everywhere and is easy to forget.
Problem
Vimcode bundles a ~13 KB Nerd Font subset at `data/fonts/vimcode-icons.ttf` for GTK. Several `Icon` constants in `src/icons.rs` reference nerd-codepoints that aren't in the subset. When the code calls `Icon::s()` (which returns the nerd variant if nerd fonts are "enabled") and the glyph is missing, Pango silently falls back to system fonts and renders an unrelated character — not the `.fallback` field the `Icon` struct also carries.
Concrete case surfaced while fixing #196: `FIND_IN_SEL.nerd = "\u{eb54}"` (nf-cod-selection) → Pango substitutes a stray `"` because the codepoint isn't in the bundled subset. Worked around in the fix by using `FIND_IN_SEL.fallback` directly for GTK.
Likely affects other icons too — whatever subset generation script was used either missed codepoints or was out of sync with icon additions.
Cross-backend impact
Suggested Fixes (ordered by scope)
Option 1 is the quick fix; 2+3 are infrastructure.
Files
Priority
Minor visual glitches accumulating. Individually dodgeable via `.fallback` workarounds (as done in #196), but the workaround needs to be applied everywhere and is easy to forget.