46 lines
3.3 KiB
Markdown
46 lines
3.3 KiB
Markdown
# fastfetch
|
|
|
|
Themes [fastfetch](https://github.com/fastfetch-cli/fastfetch) — sets `display.color.keys`,
|
|
`display.color.title`, `display.percent.color.{green,yellow,red}` and `logo.color.{1,2}`.
|
|
|
|
fastfetch's config (`~/.config/fastfetch/config.jsonc`) has no include/merge directive, so
|
|
`apply.sh` merges the rendered color object into the user's real config.jsonc directly (`jq -s
|
|
'.[0] * .[1]'`), preserving everything else in it (modules list, custom module config, etc.).
|
|
|
|
**Known limitation: strict JSON only, not full JSONC.** `jq` (used for the merge) only parses
|
|
strict JSON — `//`/`/* */` comments and trailing commas, both valid JSONC, will make `apply.sh`
|
|
fail. It fails loudly with a clear message in that case rather than silently corrupting the file
|
|
or applying nothing with no explanation. If your `config.jsonc` uses comments, remove them to use
|
|
this template (fastfetch's own `--gen-config`/`--gen-config-force` output has none by default).
|
|
Also fails loudly (rather than auto-creating one) if `config.jsonc` doesn't exist at all yet —
|
|
run fastfetch once first to generate a default config.
|
|
|
|
**Idempotency note**: the merge is guarded by comparing only the `logo`/`display` sub-objects
|
|
semantically (`jq -S`), not the whole file's raw bytes — a naive whole-file `cmp` after a `jq`
|
|
merge will never actually match hand-formatted JSON (`jq` re-serializes with its own canonical
|
|
formatting), which silently defeats the guard and rewrites the file on every apply regardless of
|
|
whether colors changed. Verified idempotent: running `apply.sh` twice with unchanged colors
|
|
leaves the file's mtime and content completely untouched.
|
|
|
|
**Known upstream bug (worked around here): `logo.color` silently drops pastel/light colors.**
|
|
Confirmed live against fastfetch 2.66.0: a `logo.color.N` value is dropped with no error — the
|
|
logo falls back to its default palette — whenever its truecolor SGR string (`38;2;R;G;B`) is
|
|
exactly 16 characters, i.e. every one of R/G/B is a 3-digit number (`>=100`). That covers a large
|
|
share of real accent colors, including most pastel/light theme colors. `display.color.keys`/
|
|
`title`/`percent` are unaffected — only `logo.color.N` goes through the broken code path.
|
|
Isolated by testing the exact byte-length trigger directly (both via `--logo-color-N` and via this
|
|
same JSON key) with fully saturated colors of the same hue (worked) vs. desaturated/light colors
|
|
producing a 16-char string (failed), including a control test with a non-pastel color that still
|
|
had all three channels `>=100` (also failed) — confirming it's the string length, not the hue or
|
|
lightness itself.
|
|
|
|
`apply.sh` routes around it: whenever a `logo.color` value would trip the bug, the single
|
|
*smallest* RGB channel is nudged down to 99 — the minimal change that drops the SGR string below
|
|
16 characters, and since it's already the channel closest to the 100 boundary, it's the smallest
|
|
possible perceptual shift (e.g. `#fff59b` → `#fff563`). An earlier version of this fix quantized
|
|
to the nearest ANSI-256 cube color instead, but the 216-color cube only has 6 steps per channel,
|
|
so a near-white pastel like `#fff59b` snapped to `#ffffaf` — visually just white on a small ascii
|
|
logo. The channel-nudge keeps full 24-bit truecolor and stays close to the real color.
|
|
|
|
Tested against fastfetch 2.66.0.
|