@promptctl/rich-js 0.6.0 → 0.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +31 -30
- package/dist/core/box.d.ts +3 -3
- package/dist/core/box.d.ts.map +1 -1
- package/dist/core/box.js.map +1 -1
- package/dist/core/cells.d.ts +46 -1
- package/dist/core/cells.d.ts.map +1 -1
- package/dist/core/cells.js +55 -14
- package/dist/core/cells.js.map +1 -1
- package/dist/core/console.d.ts +28 -10
- package/dist/core/console.d.ts.map +1 -1
- package/dist/core/console.js +141 -80
- package/dist/core/console.js.map +1 -1
- package/dist/core/markup.d.ts +0 -2
- package/dist/core/markup.d.ts.map +1 -1
- package/dist/core/markup.js +31 -17
- package/dist/core/markup.js.map +1 -1
- package/dist/core/measure.d.ts +11 -0
- package/dist/core/measure.d.ts.map +1 -1
- package/dist/core/measure.js +15 -3
- package/dist/core/measure.js.map +1 -1
- package/dist/core/oklch.d.ts +22 -0
- package/dist/core/oklch.d.ts.map +1 -1
- package/dist/core/oklch.js +62 -18
- package/dist/core/oklch.js.map +1 -1
- package/dist/core/pretty.d.ts +87 -0
- package/dist/core/pretty.d.ts.map +1 -0
- package/dist/core/pretty.js +304 -0
- package/dist/core/pretty.js.map +1 -0
- package/dist/core/protocol.d.ts +64 -0
- package/dist/core/protocol.d.ts.map +1 -1
- package/dist/core/protocol.js +72 -0
- package/dist/core/protocol.js.map +1 -1
- package/dist/core/segment.d.ts +21 -0
- package/dist/core/segment.d.ts.map +1 -1
- package/dist/core/segment.js +40 -1
- package/dist/core/segment.js.map +1 -1
- package/dist/core/subscription.d.ts +13 -0
- package/dist/core/subscription.d.ts.map +1 -0
- package/dist/core/subscription.js +13 -0
- package/dist/core/subscription.js.map +1 -0
- package/dist/core/text.d.ts.map +1 -1
- package/dist/core/text.js +45 -13
- package/dist/core/text.js.map +1 -1
- package/dist/host/host-stream.d.ts +31 -0
- package/dist/host/host-stream.d.ts.map +1 -0
- package/dist/host/host-stream.js +36 -0
- package/dist/host/host-stream.js.map +1 -0
- package/dist/host/index.d.ts +4 -0
- package/dist/host/index.d.ts.map +1 -0
- package/dist/host/index.js +3 -0
- package/dist/host/index.js.map +1 -0
- package/dist/host/terminal-host.d.ts +144 -0
- package/dist/host/terminal-host.d.ts.map +1 -0
- package/dist/host/terminal-host.js +133 -0
- package/dist/host/terminal-host.js.map +1 -0
- package/dist/index.d.ts +11 -35
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +36 -22
- package/dist/index.js.map +1 -1
- package/dist/node/terminal-host.d.ts +85 -0
- package/dist/node/terminal-host.d.ts.map +1 -0
- package/dist/node/terminal-host.js +161 -0
- package/dist/node/terminal-host.js.map +1 -0
- package/dist/node/traceback.d.ts +28 -0
- package/dist/node/traceback.d.ts.map +1 -0
- package/dist/node/traceback.js +113 -0
- package/dist/node/traceback.js.map +1 -0
- package/dist/renderables/columns.d.ts +24 -2
- package/dist/renderables/columns.d.ts.map +1 -1
- package/dist/renderables/columns.js +91 -32
- package/dist/renderables/columns.js.map +1 -1
- package/dist/renderables/layout.d.ts +61 -5
- package/dist/renderables/layout.d.ts.map +1 -1
- package/dist/renderables/layout.js +191 -19
- package/dist/renderables/layout.js.map +1 -1
- package/dist/renderables/padding.d.ts +15 -2
- package/dist/renderables/padding.d.ts.map +1 -1
- package/dist/renderables/padding.js +92 -37
- package/dist/renderables/padding.js.map +1 -1
- package/dist/renderables/panel.d.ts +44 -3
- package/dist/renderables/panel.d.ts.map +1 -1
- package/dist/renderables/panel.js +149 -80
- package/dist/renderables/panel.js.map +1 -1
- package/dist/renderables/table.d.ts +40 -4
- package/dist/renderables/table.d.ts.map +1 -1
- package/dist/renderables/table.js +276 -158
- package/dist/renderables/table.js.map +1 -1
- package/dist/renderables/traceback.d.ts +6 -2
- package/dist/renderables/traceback.d.ts.map +1 -1
- package/dist/renderables/traceback.js +6 -10
- package/dist/renderables/traceback.js.map +1 -1
- package/dist/renderables/tree.d.ts +27 -2
- package/dist/renderables/tree.d.ts.map +1 -1
- package/dist/renderables/tree.js +82 -23
- package/dist/renderables/tree.js.map +1 -1
- package/dist/template-bindings/color-funcs.d.ts +78 -0
- package/dist/template-bindings/color-funcs.d.ts.map +1 -0
- package/dist/template-bindings/color-funcs.js +212 -0
- package/dist/template-bindings/color-funcs.js.map +1 -0
- package/dist/template-bindings/index.d.ts +24 -18
- package/dist/template-bindings/index.d.ts.map +1 -1
- package/dist/template-bindings/index.js +26 -19
- package/dist/template-bindings/index.js.map +1 -1
- package/dist/template-bindings/palette-funcs.d.ts +70 -51
- package/dist/template-bindings/palette-funcs.d.ts.map +1 -1
- package/dist/template-bindings/palette-funcs.js +120 -125
- package/dist/template-bindings/palette-funcs.js.map +1 -1
- package/dist/template-bindings/style-funcs.d.ts +11 -12
- package/dist/template-bindings/style-funcs.d.ts.map +1 -1
- package/dist/template-bindings/style-funcs.js +48 -74
- package/dist/template-bindings/style-funcs.js.map +1 -1
- package/dist/themes/buildPalette.d.ts +7 -1
- package/dist/themes/buildPalette.d.ts.map +1 -1
- package/dist/themes/buildPalette.js +15 -1
- package/dist/themes/buildPalette.js.map +1 -1
- package/dist/themes/colorRef.d.ts +52 -0
- package/dist/themes/colorRef.d.ts.map +1 -0
- package/dist/themes/colorRef.js +97 -0
- package/dist/themes/colorRef.js.map +1 -0
- package/dist/themes/palette.d.ts +4 -2
- package/dist/themes/palette.d.ts.map +1 -1
- package/dist/themes/palette.js +4 -2
- package/dist/themes/palette.js.map +1 -1
- package/dist/themes/ramp.d.ts +84 -0
- package/dist/themes/ramp.d.ts.map +1 -0
- package/dist/themes/ramp.js +123 -0
- package/dist/themes/ramp.js.map +1 -0
- package/dist/widgets/dropdown.d.ts +1 -1
- package/dist/widgets/dropdown.js +1 -1
- package/dist/widgets/event-router.d.ts +3 -2
- package/dist/widgets/event-router.d.ts.map +1 -1
- package/dist/widgets/focus-manager.d.ts +2 -1
- package/dist/widgets/focus-manager.d.ts.map +1 -1
- package/dist/widgets/index.d.ts +3 -6
- package/dist/widgets/index.d.ts.map +1 -1
- package/dist/widgets/index.js +4 -3
- package/dist/widgets/index.js.map +1 -1
- package/dist/widgets/screen.d.ts +1 -1
- package/dist/widgets/screen.d.ts.map +1 -1
- package/dist/widgets/terminal-host.d.ts +13 -63
- package/dist/widgets/terminal-host.d.ts.map +1 -1
- package/dist/widgets/terminal-host.js +11 -142
- package/dist/widgets/terminal-host.js.map +1 -1
- package/dist/widgets/text-input.d.ts +2 -3
- package/dist/widgets/text-input.d.ts.map +1 -1
- package/dist/widgets/text-input.js +4 -12
- package/dist/widgets/text-input.js.map +1 -1
- package/dist/widgets/types.d.ts +1 -1
- package/dist/widgets/types.d.ts.map +1 -1
- package/dist/widgets/types.js.map +1 -1
- package/dist/widgets/widget-base.d.ts +2 -1
- package/dist/widgets/widget-base.d.ts.map +1 -1
- package/package.json +20 -4
|
@@ -1,157 +1,152 @@
|
|
|
1
1
|
/**
|
|
2
|
-
*
|
|
3
|
-
*
|
|
2
|
+
* The palette-dependent template functions: `color`, and `ramp` whose stops
|
|
3
|
+
* are color references.
|
|
4
4
|
*
|
|
5
|
-
*
|
|
6
|
-
* `PaletteResolver.resolve(spec, ctx)` API — this module adds no resolution
|
|
7
|
-
* logic of its own. The template functions here are thin adaptors that translate
|
|
8
|
-
* function call arguments into a `(spec, ctx)` call and wrap the resulting
|
|
9
|
-
* `ColorRgba` as a `Style` applied to the child fragment.
|
|
5
|
+
* ### Why `color` is the one name resolver
|
|
10
6
|
*
|
|
11
|
-
*
|
|
12
|
-
*
|
|
13
|
-
*
|
|
14
|
-
*
|
|
7
|
+
* This module used to register four kinds of thing: one function per
|
|
8
|
+
* identifier-safe palette variable (`{{ primary child }}`, `{{ accent child }}`,
|
|
9
|
+
* …), a general `palette "spec" child`, a `paletteOver "spec" "#bg" child` for
|
|
10
|
+
* specs needing a background, and an `auto "#bg" child` sugar. That surface had
|
|
11
|
+
* two defects worth recording, because both are easy to reintroduce.
|
|
15
12
|
*
|
|
16
|
-
*
|
|
13
|
+
* **The name family could not cover its own domain.** A themed palette carries
|
|
14
|
+
* ~150 variables; roughly 14 of them are legal Go-template identifiers. So the
|
|
15
|
+
* generated functions reached under a tenth of the palette, and the other nine
|
|
16
|
+
* tenths needed `palette "text-primary" child` — a *different expression shape*
|
|
17
|
+
* for the same intent. An author who learned `{{ primary x }}` and reasonably
|
|
18
|
+
* tried `{{ text_primary x }}` got a FuncNotFound. [LAW:composability] — the
|
|
19
|
+
* `filterByStatus`/`filterByOwner` shape: names cannot enumerate a domain, and
|
|
20
|
+
* the N+1 case always needs a form you have to learn separately.
|
|
17
21
|
*
|
|
18
|
-
*
|
|
22
|
+
* **Resolution and application were fused.** Every one of those functions
|
|
23
|
+
* consumed its color instantly into a styled fragment, so a color could never
|
|
24
|
+
* be held or passed. Composition therefore had to happen inside the spec
|
|
25
|
+
* *string* — hence the old `name-darken-N alpha%` grammar. See
|
|
26
|
+
* `color-funcs.ts` for the full argument; the short version is that a string
|
|
27
|
+
* grammar is function application with the function calls spelled as
|
|
28
|
+
* punctuation, and it grows a new production for every operation.
|
|
19
29
|
*
|
|
20
|
-
*
|
|
21
|
-
*
|
|
22
|
-
*
|
|
23
|
-
*
|
|
24
|
-
* cannot be Go template identifiers and are accessed via `palette`.
|
|
30
|
+
* What replaces all of it: `color "name-or-hex"` produces a color value, the
|
|
31
|
+
* functions in `color-funcs.ts` transform colors, and `fg`/`bg` in
|
|
32
|
+
* `style-funcs.ts` paint them. One shape, total over the palette, open to
|
|
33
|
+
* arbitrary composition. [LAW:one-type-per-behavior]
|
|
25
34
|
*
|
|
26
|
-
*
|
|
27
|
-
* that does not need a background context (bare names and darken/lighten
|
|
28
|
-
* modifiers). Covers hyphenated names and modifier chains.
|
|
35
|
+
* ### Why `ramp` lives here and not with the color math
|
|
29
36
|
*
|
|
30
|
-
*
|
|
31
|
-
*
|
|
32
|
-
*
|
|
33
|
-
*
|
|
34
|
-
*
|
|
37
|
+
* `ramp` is the one function whose input is a *number*, and its stops are
|
|
38
|
+
* spelled as color references — `ramp .pct "step" 0 "panel" 50 "warning" 80
|
|
39
|
+
* "error"` — resolved through the same `resolveColorRef` that `color` crosses.
|
|
40
|
+
* Requiring `(color "panel")` around every stop would put the boilerplate
|
|
41
|
+
* back that this binding exists to remove, and an author who writes a hex
|
|
42
|
+
* literal loses nothing: the resolver is idempotent on hex. The arithmetic
|
|
43
|
+
* itself is `ColorRamp` in `themes/ramp.ts`, palette-free; only the
|
|
44
|
+
* reference resolution is here. [LAW:one-way-deps]
|
|
35
45
|
*
|
|
36
|
-
*
|
|
37
|
-
* `{{ paletteOver "auto" "#bgHex" child }}`, the common auto-contrast case.
|
|
46
|
+
* ### Why a getter, not a palette
|
|
38
47
|
*
|
|
39
|
-
*
|
|
48
|
+
* `paletteFuncs` takes `() => Palette` rather than a `Palette`. A consumer
|
|
49
|
+
* whose theme can change at runtime (a live preview, a theme picker, a
|
|
50
|
+
* status-line that recolors on click) would otherwise be frozen to whichever
|
|
51
|
+
* palette happened to be current when the engine was constructed — and since
|
|
52
|
+
* templates are parsed once and evaluated many times, that freeze outlives
|
|
53
|
+
* every subsequent theme change while the *rest* of the consumer's colors move
|
|
54
|
+
* on. Two palettes, one render: [LAW:one-source-of-truth] violated by a
|
|
55
|
+
* captured reference.
|
|
40
56
|
*
|
|
41
|
-
*
|
|
42
|
-
*
|
|
43
|
-
*
|
|
44
|
-
*
|
|
45
|
-
* the
|
|
57
|
+
* The getter costs nothing structurally. `FuncMap` entries are data in the
|
|
58
|
+
* engine and their bodies run at *evaluate* time, so reading the palette
|
|
59
|
+
* through a getter leaves parse-once/evaluate-many completely intact. What the
|
|
60
|
+
* getter must not change is *which functions exist* — and it cannot, because
|
|
61
|
+
* the two names here do not depend on the palette's contents. That was not
|
|
62
|
+
* true of the generated per-variable functions, which is the second reason
|
|
63
|
+
* they are gone.
|
|
46
64
|
*/
|
|
47
|
-
import {
|
|
48
|
-
import {
|
|
49
|
-
import { applyStyleToFragment } from "./helpers.js";
|
|
50
|
-
// Regex for validating hex bg strings accepted by `paletteOver` and `auto`.
|
|
51
|
-
// Accepts #RRGGBB and #RRGGBBAA — same gate as the `hex` style function.
|
|
52
|
-
const HEX_BG_RE = /^#[0-9a-fA-F]{6}([0-9a-fA-F]{2})?$/;
|
|
65
|
+
import { resolveColorRef } from "../themes/colorRef.js";
|
|
66
|
+
import { ColorRamp, parseRampEasing } from "../themes/ramp.js";
|
|
53
67
|
/**
|
|
54
|
-
*
|
|
55
|
-
* Throws `RangeError` on invalid input — surfaces as an `EvalError` in the
|
|
56
|
-
* template engine, giving the author a precise failure message.
|
|
57
|
-
*/
|
|
58
|
-
function hexToColorRgba(hex) {
|
|
59
|
-
if (!HEX_BG_RE.test(hex)) {
|
|
60
|
-
throw new RangeError(`palette background expected #RRGGBB or #RRGGBBAA, got ${JSON.stringify(hex)}`);
|
|
61
|
-
}
|
|
62
|
-
// ColorSpec.parse("#RRGGBB") → TRUECOLOR spec; getTruecolor() returns value directly.
|
|
63
|
-
return ColorSpec.parse(hex).getTruecolor();
|
|
64
|
-
}
|
|
65
|
-
/**
|
|
66
|
-
* Resolve `spec` against the resolver (with optional background context) and
|
|
67
|
-
* apply the resulting color as a foreground `Style` on `child`.
|
|
68
|
+
* The `(position, color-ref)` pairs a `ramp` call's tail spells, as stops.
|
|
68
69
|
*
|
|
69
|
-
*
|
|
70
|
-
*
|
|
70
|
+
* The engine's `alternating` gate has already typed every even slot as a
|
|
71
|
+
* float and every odd slot as a string; what it cannot see is the *pairing*
|
|
72
|
+
* — a trailing position with no color — nor that the string is a color
|
|
73
|
+
* reference. Both are settled here, once, and `ColorRamp` receives resolved
|
|
74
|
+
* stops it never re-checks. [LAW:parse-dont-validate]
|
|
75
|
+
*
|
|
76
|
+
* Each reference resolves against the palette of *this* evaluation, so a
|
|
77
|
+
* ramp over palette names follows the theme exactly as `color` does.
|
|
71
78
|
*/
|
|
72
|
-
function
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
const hint = against === undefined
|
|
76
|
-
? "; for specs with alpha or auto-contrast, use paletteOver"
|
|
77
|
-
: "";
|
|
78
|
-
throw new Error(`palette spec ${JSON.stringify(spec)} did not resolve — check the spec string is valid and the variable exists${hint}`);
|
|
79
|
+
function colorStops(tail, palette) {
|
|
80
|
+
if (tail.length === 0) {
|
|
81
|
+
throw new RangeError(`ramp needs at least one stop after the easing: ramp <value> <easing> <position> <color> …`);
|
|
79
82
|
}
|
|
80
|
-
|
|
81
|
-
}
|
|
82
|
-
|
|
83
|
-
// identifiers (letter/underscore start, alphanumeric/underscore body) get
|
|
84
|
-
// individual functions. Hyphenated names like "primary-muted" parse as subtraction
|
|
85
|
-
// in Go template syntax and cannot be function names.
|
|
86
|
-
const IDENTIFIER_RE = /^[A-Za-z_][A-Za-z0-9_]*$/;
|
|
87
|
-
function semanticNameFuncs(resolver) {
|
|
88
|
-
const out = {};
|
|
89
|
-
for (const name of resolver.palette.vars.keys()) {
|
|
90
|
-
if (!IDENTIFIER_RE.test(name))
|
|
91
|
-
continue;
|
|
92
|
-
// [LAW:dataflow-not-control-flow] Capture name; same fn shape for every entry.
|
|
93
|
-
const captured = name;
|
|
94
|
-
out[captured] = {
|
|
95
|
-
fn: ((child) => resolveAndApply(resolver, captured, undefined, child)),
|
|
96
|
-
argTypes: ["liftable"],
|
|
97
|
-
returnType: "T",
|
|
98
|
-
};
|
|
83
|
+
if (tail.length % 2 !== 0) {
|
|
84
|
+
throw new RangeError(`ramp's last stop (position ${String(tail[tail.length - 1])}) has no color — ` +
|
|
85
|
+
`stops are <position> <color> pairs`);
|
|
99
86
|
}
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
}
|
|
109
|
-
function makePaletteOverFunc(resolver) {
|
|
110
|
-
return {
|
|
111
|
-
fn: ((spec, bgHex, child) => resolveAndApply(resolver, spec, hexToColorRgba(bgHex), child)),
|
|
112
|
-
argTypes: ["string", "string", "liftable"],
|
|
113
|
-
returnType: "T",
|
|
114
|
-
};
|
|
115
|
-
}
|
|
116
|
-
function makeAutoFunc(resolver) {
|
|
117
|
-
return {
|
|
118
|
-
fn: ((bgHex, child) => resolveAndApply(resolver, "auto", hexToColorRgba(bgHex), child)),
|
|
119
|
-
argTypes: ["string", "liftable"],
|
|
120
|
-
returnType: "T",
|
|
121
|
-
};
|
|
87
|
+
const stops = [];
|
|
88
|
+
for (let i = 0; i < tail.length; i += 2) {
|
|
89
|
+
stops.push({
|
|
90
|
+
at: tail[i],
|
|
91
|
+
color: resolveColorRef(palette, tail[i + 1]),
|
|
92
|
+
});
|
|
93
|
+
}
|
|
94
|
+
return stops;
|
|
122
95
|
}
|
|
123
96
|
/**
|
|
124
|
-
*
|
|
125
|
-
*
|
|
126
|
-
* palette
|
|
97
|
+
* Register `color "name-or-hex"` against a live palette.
|
|
98
|
+
*
|
|
99
|
+
* `color` resolves a palette variable name to a `#RRGGBB` string, and passes
|
|
100
|
+
* an already-literal color through unchanged. That second half is not a
|
|
101
|
+
* convenience — it makes `color` **idempotent**, which is what lets consumers
|
|
102
|
+
* apply it unconditionally to any author-written color string without first
|
|
103
|
+
* asking whether it is a name or already a color. [LAW:dataflow-not-control-flow]
|
|
127
104
|
*
|
|
128
|
-
*
|
|
129
|
-
*
|
|
130
|
-
*
|
|
131
|
-
*
|
|
132
|
-
* - `paletteOver "spec" "#bgHex" child` — any spec needing a background (alpha,
|
|
133
|
-
* auto-contrast).
|
|
134
|
-
* - `auto "#bgHex" child` — sugar for `paletteOver "auto" bgHex child`.
|
|
105
|
+
* An unknown name throws, carrying near-miss suggestions from the live
|
|
106
|
+
* palette. In a template that surfaces as an evaluation error at the exact
|
|
107
|
+
* call site, which is the signal an author (or an agent editing a config) needs
|
|
108
|
+
* to fix it. [LAW:no-silent-failure]
|
|
135
109
|
*
|
|
136
110
|
* @example
|
|
137
111
|
* ```ts
|
|
138
|
-
* import { createEngine } from "@promptctl/go-template-js";
|
|
139
|
-
* import { GRUVBOX, PaletteResolver, RichText } from "rich-js";
|
|
140
|
-
* import { richTextFuncs, paletteFuncs } from "rich-js/template-bindings";
|
|
141
|
-
*
|
|
142
112
|
* const engine = createEngine({
|
|
143
113
|
* fromString: (s) => new RichText(s),
|
|
144
114
|
* toString: (rt) => rt.plain,
|
|
145
|
-
* funcs: {
|
|
115
|
+
* funcs: {
|
|
116
|
+
* ...richTextFuncs(),
|
|
117
|
+
* ...colorFuncs(),
|
|
118
|
+
* ...paletteFuncs(() => currentTheme.palette),
|
|
119
|
+
* },
|
|
146
120
|
* });
|
|
147
121
|
* ```
|
|
148
122
|
*/
|
|
149
|
-
export function paletteFuncs(
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
123
|
+
export function paletteFuncs(getPalette) {
|
|
124
|
+
const colorFunc = {
|
|
125
|
+
fn: ((ref) => resolveColorRef(getPalette(), ref).hex),
|
|
126
|
+
argTypes: ["string"],
|
|
127
|
+
returnType: "string",
|
|
128
|
+
};
|
|
129
|
+
// `ramp <value> <easing> <position> <color> …` — the argument list is one
|
|
130
|
+
// float/string cycle end to end (value, easing, then each stop's position
|
|
131
|
+
// and color), so the engine's `alternating` gate types every slot; the
|
|
132
|
+
// pairing and the references are parsed in `colorStops`.
|
|
133
|
+
// [LAW:types-are-the-program]
|
|
134
|
+
const rampFunc = {
|
|
135
|
+
fn: ((...args) => {
|
|
136
|
+
// The engine's `alternating` gate types each slot but sets no minimum
|
|
137
|
+
// count, so `{{ ramp }}` and `{{ ramp 65 }}` both reach here: one
|
|
138
|
+
// check over the whole list, naming what is missing. [LAW:no-silent-failure]
|
|
139
|
+
if (args.length < 2) {
|
|
140
|
+
throw new RangeError(`ramp needs a value and an easing before its stops (got ${args.length}): ` +
|
|
141
|
+
`ramp <value> "linear"|"step" <position> <color> …`);
|
|
142
|
+
}
|
|
143
|
+
const [value, easing, ...tail] = args;
|
|
144
|
+
return new ColorRamp(parseRampEasing(easing), colorStops(tail, getPalette())).at(value).hex;
|
|
145
|
+
}),
|
|
146
|
+
argTypes: ["float", "string"],
|
|
147
|
+
argTypePattern: "alternating",
|
|
148
|
+
returnType: "string",
|
|
155
149
|
};
|
|
150
|
+
return { color: colorFunc, ramp: rampFunc };
|
|
156
151
|
}
|
|
157
152
|
//# sourceMappingURL=palette-funcs.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"palette-funcs.js","sourceRoot":"","sources":["../../src/template-bindings/palette-funcs.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"palette-funcs.js","sourceRoot":"","sources":["../../src/template-bindings/palette-funcs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+DG;AAIH,OAAO,EAAE,eAAe,EAAE,MAAM,uBAAuB,CAAC;AACxD,OAAO,EAAE,SAAS,EAAE,eAAe,EAAkB,MAAM,mBAAmB,CAAC;AAE/E;;;;;;;;;;;GAWG;AACH,SAAS,UAAU,CAAC,IAAwB,EAAE,OAAgB;IAC5D,IAAI,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACtB,MAAM,IAAI,UAAU,CAClB,2FAA2F,CAC5F,CAAC;IACJ,CAAC;IACD,IAAI,IAAI,CAAC,MAAM,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC;QAC1B,MAAM,IAAI,UAAU,CAClB,8BAA8B,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,mBAAmB;YAC5E,oCAAoC,CACvC,CAAC;IACJ,CAAC;IACD,MAAM,KAAK,GAAgB,EAAE,CAAC;IAC9B,KAAK,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,GAAG,IAAI,CAAC,MAAM,EAAE,CAAC,IAAI,CAAC,EAAE,CAAC;QACxC,KAAK,CAAC,IAAI,CAAC;YACT,EAAE,EAAE,IAAI,CAAC,CAAC,CAAW;YACrB,KAAK,EAAE,eAAe,CAAC,OAAO,EAAE,IAAI,CAAC,CAAC,GAAG,CAAC,CAAW,CAAC;SACvD,CAAC,CAAC;IACL,CAAC;IACD,OAAO,KAAK,CAAC;AACf,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,MAAM,UAAU,YAAY,CAAC,UAAyB;IACpD,MAAM,SAAS,GAAiB;QAC9B,EAAE,EAAE,CAAC,CAAC,GAAW,EAAE,EAAE,CAAC,eAAe,CAAC,UAAU,EAAE,EAAE,GAAG,CAAC,CAAC,GAAG,CAAuB;QACnF,QAAQ,EAAE,CAAC,QAAQ,CAAC;QACpB,UAAU,EAAE,QAAQ;KACrB,CAAC;IACF,0EAA0E;IAC1E,0EAA0E;IAC1E,uEAAuE;IACvE,yDAAyD;IACzD,8BAA8B;IAC9B,MAAM,QAAQ,GAAiB;QAC7B,EAAE,EAAE,CAAC,CAAC,GAAG,IAAe,EAAE,EAAE;YAC1B,sEAAsE;YACtE,kEAAkE;YAClE,6EAA6E;YAC7E,IAAI,IAAI,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;gBACpB,MAAM,IAAI,UAAU,CAClB,0DAA0D,IAAI,CAAC,MAAM,KAAK;oBACxE,mDAAmD,CACtD,CAAC;YACJ,CAAC;YACD,MAAM,CAAC,KAAK,EAAE,MAAM,EAAE,GAAG,IAAI,CAAC,GAAG,IAAsC,CAAC;YACxE,OAAO,IAAI,SAAS,CAAC,eAAe,CAAC,MAAM,CAAC,EAAE,UAAU,CAAC,IAAI,EAAE,UAAU,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC;QAC9F,CAAC,CAAuB;QACxB,QAAQ,EAAE,CAAC,OAAO,EAAE,QAAQ,CAAC;QAC7B,cAAc,EAAE,aAAa;QAC7B,UAAU,EAAE,QAAQ;KACrB,CAAC;IACF,OAAO,EAAE,KAAK,EAAE,SAAS,EAAE,IAAI,EAAE,QAAQ,EAAE,CAAC;AAC9C,CAAC"}
|
|
@@ -2,12 +2,11 @@
|
|
|
2
2
|
* Style-function registrations for the rich-js template binding.
|
|
3
3
|
*
|
|
4
4
|
* [LAW:one-source-of-truth] The function inventory below mirrors the
|
|
5
|
-
* string-syntax style vocabulary documented in `
|
|
6
|
-
*
|
|
7
|
-
*
|
|
8
|
-
*
|
|
9
|
-
*
|
|
10
|
-
* round-trips through `Style` without semantic drift.
|
|
5
|
+
* string-syntax style vocabulary documented in `docs/style.md` — the two
|
|
6
|
+
* colour slots (`fg`/`bg`), text attributes (positive + negated), short
|
|
7
|
+
* aliases, and the hyperlink. Each registration is a templating-time analogue
|
|
8
|
+
* of a piece of `Style.parse`, so a template fragment composed by these
|
|
9
|
+
* functions round-trips through `Style` without semantic drift.
|
|
11
10
|
*
|
|
12
11
|
* [LAW:dataflow-not-control-flow] Every function follows the same
|
|
13
12
|
* shape: child `RichText` in, `RichText` out. The styling difference
|
|
@@ -18,13 +17,13 @@
|
|
|
18
17
|
*/
|
|
19
18
|
import type { FuncMap } from "@promptctl/go-template-js";
|
|
20
19
|
/**
|
|
21
|
-
*
|
|
22
|
-
*
|
|
23
|
-
* (`
|
|
24
|
-
* negations), and the hyperlink cell-splitter (`link`).
|
|
20
|
+
* Text-styling registrations: the two colour sinks (`fg`, `bg`), text
|
|
21
|
+
* attributes (canonical names, short aliases, and `not_*` negations), the
|
|
22
|
+
* hyperlink cell-splitter (`link`), and the multi-attribute `style` spec.
|
|
25
23
|
*
|
|
26
|
-
*
|
|
27
|
-
*
|
|
24
|
+
* Colours themselves come from elsewhere: `colorFuncs()` for the palette-free
|
|
25
|
+
* math, `paletteFuncs()` for naming a theme colour. This module only paints.
|
|
26
|
+
* [LAW:one-way-deps] — nothing here imports a palette.
|
|
28
27
|
*/
|
|
29
28
|
export declare function richTextStyleFuncs(): FuncMap;
|
|
30
29
|
//# sourceMappingURL=style-funcs.d.ts.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"style-funcs.d.ts","sourceRoot":"","sources":["../../src/template-bindings/style-funcs.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"style-funcs.d.ts","sourceRoot":"","sources":["../../src/template-bindings/style-funcs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH,OAAO,KAAK,EAAE,OAAO,EAAgB,MAAM,2BAA2B,CAAC;AA0IvE;;;;;;;;GAQG;AACH,wBAAgB,kBAAkB,IAAI,OAAO,CAQ5C"}
|
|
@@ -2,12 +2,11 @@
|
|
|
2
2
|
* Style-function registrations for the rich-js template binding.
|
|
3
3
|
*
|
|
4
4
|
* [LAW:one-source-of-truth] The function inventory below mirrors the
|
|
5
|
-
* string-syntax style vocabulary documented in `
|
|
6
|
-
*
|
|
7
|
-
*
|
|
8
|
-
*
|
|
9
|
-
*
|
|
10
|
-
* round-trips through `Style` without semantic drift.
|
|
5
|
+
* string-syntax style vocabulary documented in `docs/style.md` — the two
|
|
6
|
+
* colour slots (`fg`/`bg`), text attributes (positive + negated), short
|
|
7
|
+
* aliases, and the hyperlink. Each registration is a templating-time analogue
|
|
8
|
+
* of a piece of `Style.parse`, so a template fragment composed by these
|
|
9
|
+
* functions round-trips through `Style` without semantic drift.
|
|
11
10
|
*
|
|
12
11
|
* [LAW:dataflow-not-control-flow] Every function follows the same
|
|
13
12
|
* shape: child `RichText` in, `RichText` out. The styling difference
|
|
@@ -17,66 +16,44 @@
|
|
|
17
16
|
* variability; the operation is fixed.
|
|
18
17
|
*/
|
|
19
18
|
import { Style, ATTRIBUTE_NAMES, ATTRIBUTE_SHORT_ALIASES, } from "../core/style.js";
|
|
20
|
-
import { ColorSpec
|
|
19
|
+
import { ColorSpec } from "../core/color.js";
|
|
21
20
|
import { applyStyleToFragment } from "./helpers.js";
|
|
22
|
-
function
|
|
21
|
+
function attrFunc(style) {
|
|
23
22
|
return {
|
|
24
23
|
fn: ((child) => applyStyleToFragment(child, style)),
|
|
25
24
|
argTypes: ["liftable"],
|
|
26
25
|
returnType: "T",
|
|
27
26
|
};
|
|
28
27
|
}
|
|
29
|
-
// ---
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
28
|
+
// --- Colour sinks ---
|
|
29
|
+
//
|
|
30
|
+
// `fg` and `bg` are the only two colour-applying functions, and they are the
|
|
31
|
+
// terminal step of the colour pipeline: `color` names a colour, the functions
|
|
32
|
+
// in `color-funcs.ts` transform it, these paint it onto text.
|
|
33
|
+
//
|
|
34
|
+
// [LAW:composability] They replace five separate families — one function per
|
|
35
|
+
// ANSI colour name (`red`, `bright_blue`, …), `hex`, `rgb`, `color` (256-index),
|
|
36
|
+
// and `on` (background). Every one of those encoded *which colour* in the
|
|
37
|
+
// function's identity, so the vocabulary could only grow by adding names, and
|
|
38
|
+
// a colour computed at render time could not be applied at all. Here the colour
|
|
39
|
+
// is an argument, so the sink admits every colour that exists and every colour
|
|
40
|
+
// that will ever exist. Two functions, unbounded reach.
|
|
41
|
+
//
|
|
42
|
+
// [LAW:types-are-the-program] The slot accepts the full `ColorSpec.parse`
|
|
43
|
+
// vocabulary, which is wider than the hex the colour math produces — and that
|
|
44
|
+
// width is deliberate, not laxity. `#7aa2f7` is a *concrete* colour; `"red"`
|
|
45
|
+
// and `"color(42)"` are *symbolic* ones the terminal resolves against its own
|
|
46
|
+
// theme. Only concrete colours can be darkened or blended, which is why the
|
|
47
|
+
// colour-math functions take hex alone; but both kinds can be painted, so the
|
|
48
|
+
// sink takes the union. The type of each slot is exactly the set of values that
|
|
49
|
+
// slot can mean something for.
|
|
50
|
+
function colorSinkFunc(slot) {
|
|
51
|
+
return {
|
|
52
|
+
fn: ((spec, child) => applyStyleToFragment(child, new Style({ [slot]: ColorSpec.parse(spec) }))),
|
|
53
|
+
argTypes: ["string", "liftable"],
|
|
54
|
+
returnType: "T",
|
|
55
|
+
};
|
|
37
56
|
}
|
|
38
|
-
// --- Foreground colours: generic forms ---
|
|
39
|
-
const colorPaletteFunc = {
|
|
40
|
-
fn: ((index, child) => {
|
|
41
|
-
if (!Number.isInteger(index) || index < 0 || index > 255) {
|
|
42
|
-
throw new RangeError(`color index ${index} is out of range (0-255)`);
|
|
43
|
-
}
|
|
44
|
-
return applyStyleToFragment(child, new Style({ color: ColorSpec.fromAnsi(index) }));
|
|
45
|
-
}),
|
|
46
|
-
argTypes: ["int", "liftable"],
|
|
47
|
-
returnType: "T",
|
|
48
|
-
};
|
|
49
|
-
// [LAW:types-are-the-program] `hex` advertises a narrower domain than the
|
|
50
|
-
// general colour-spec parser — only `#RRGGBB` / `#RRGGBBAA` is admitted.
|
|
51
|
-
// Without this gate, `ColorSpec.parse` would silently accept any colour-spec
|
|
52
|
-
// string (named colours, `rgb(...)`, `color(N)`), letting `hex "red"` succeed
|
|
53
|
-
// and masking author mistakes.
|
|
54
|
-
const HEX_INPUT_RE = /^#[0-9a-fA-F]{6}([0-9a-fA-F]{2})?$/;
|
|
55
|
-
const colorHexFunc = {
|
|
56
|
-
fn: ((hex, child) => {
|
|
57
|
-
if (!HEX_INPUT_RE.test(hex)) {
|
|
58
|
-
throw new RangeError(`hex expected #RRGGBB or #RRGGBBAA, got ${JSON.stringify(hex)}`);
|
|
59
|
-
}
|
|
60
|
-
return applyStyleToFragment(child, new Style({ color: ColorSpec.parse(hex) }));
|
|
61
|
-
}),
|
|
62
|
-
argTypes: ["string", "liftable"],
|
|
63
|
-
returnType: "T",
|
|
64
|
-
};
|
|
65
|
-
const colorRgbFunc = {
|
|
66
|
-
fn: ((r, g, b, child) => {
|
|
67
|
-
return applyStyleToFragment(child, new Style({ color: ColorSpec.fromRgb(r, g, b) }));
|
|
68
|
-
}),
|
|
69
|
-
argTypes: ["int", "int", "int", "liftable"],
|
|
70
|
-
returnType: "T",
|
|
71
|
-
};
|
|
72
|
-
// --- Background ---
|
|
73
|
-
const onFunc = {
|
|
74
|
-
fn: ((spec, child) => {
|
|
75
|
-
return applyStyleToFragment(child, new Style({ bgcolor: ColorSpec.parse(spec) }));
|
|
76
|
-
}),
|
|
77
|
-
argTypes: ["string", "liftable"],
|
|
78
|
-
returnType: "T",
|
|
79
|
-
};
|
|
80
57
|
// --- Text attributes ---
|
|
81
58
|
//
|
|
82
59
|
// [LAW:one-source-of-truth] The attribute and short-alias inventories
|
|
@@ -89,11 +66,11 @@ function attrStyle(name, value) {
|
|
|
89
66
|
function attributeFuncs() {
|
|
90
67
|
const out = {};
|
|
91
68
|
for (const name of ATTRIBUTE_NAMES) {
|
|
92
|
-
out[name] =
|
|
93
|
-
out[`not_${name}`] =
|
|
69
|
+
out[name] = attrFunc(attrStyle(name, true));
|
|
70
|
+
out[`not_${name}`] = attrFunc(attrStyle(name, false));
|
|
94
71
|
}
|
|
95
72
|
for (const [alias, canonical] of Object.entries(ATTRIBUTE_SHORT_ALIASES)) {
|
|
96
|
-
out[alias] =
|
|
73
|
+
out[alias] = attrFunc(attrStyle(canonical, true));
|
|
97
74
|
}
|
|
98
75
|
return out;
|
|
99
76
|
}
|
|
@@ -105,7 +82,7 @@ function attributeFuncs() {
|
|
|
105
82
|
// byte-equivalent to the same spec inside markup, and one that `Style.parse`
|
|
106
83
|
// rejects raises the same `StyleSyntaxError` surface.
|
|
107
84
|
//
|
|
108
|
-
// Motivation: the per-attribute functions (`bold`, `underline`, `
|
|
85
|
+
// Motivation: the per-attribute functions (`bold`, `underline`, `fg`, …)
|
|
109
86
|
// compose by nesting. For "apply a fixed set of styles to this child" or
|
|
110
87
|
// "apply this named style set everywhere", nesting is awkward and the
|
|
111
88
|
// style description is fragmented across multiple call sites. `style`
|
|
@@ -138,7 +115,7 @@ const styleSpecFunc = {
|
|
|
138
115
|
//
|
|
139
116
|
// The cell-boundary signal that consumers (cc-candybar et al.) walk is
|
|
140
117
|
// `fragment.style.link` being truthy. `Style.add` propagates `link`
|
|
141
|
-
// through any outer wrapping call, so `{{ red (link "u" "x") }}` and
|
|
118
|
+
// through any outer wrapping call, so `{{ fg "red" (link "u" "x") }}` and
|
|
142
119
|
// `{{ link "u" "x" }}` produce shapes that both qualify as cells from
|
|
143
120
|
// the consumer's perspective. Outer-wins on nested links comes for free
|
|
144
121
|
// from `Style.add`'s right-wins-on-conflict rule.
|
|
@@ -155,21 +132,18 @@ const linkFunc = {
|
|
|
155
132
|
};
|
|
156
133
|
// --- Public assembly ---
|
|
157
134
|
/**
|
|
158
|
-
*
|
|
159
|
-
*
|
|
160
|
-
* (`
|
|
161
|
-
* negations), and the hyperlink cell-splitter (`link`).
|
|
135
|
+
* Text-styling registrations: the two colour sinks (`fg`, `bg`), text
|
|
136
|
+
* attributes (canonical names, short aliases, and `not_*` negations), the
|
|
137
|
+
* hyperlink cell-splitter (`link`), and the multi-attribute `style` spec.
|
|
162
138
|
*
|
|
163
|
-
*
|
|
164
|
-
*
|
|
139
|
+
* Colours themselves come from elsewhere: `colorFuncs()` for the palette-free
|
|
140
|
+
* math, `paletteFuncs()` for naming a theme colour. This module only paints.
|
|
141
|
+
* [LAW:one-way-deps] — nothing here imports a palette.
|
|
165
142
|
*/
|
|
166
143
|
export function richTextStyleFuncs() {
|
|
167
144
|
return {
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
hex: colorHexFunc,
|
|
171
|
-
rgb: colorRgbFunc,
|
|
172
|
-
on: onFunc,
|
|
145
|
+
fg: colorSinkFunc("color"),
|
|
146
|
+
bg: colorSinkFunc("bgcolor"),
|
|
173
147
|
...attributeFuncs(),
|
|
174
148
|
link: linkFunc,
|
|
175
149
|
style: styleSpecFunc,
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"style-funcs.js","sourceRoot":"","sources":["../../src/template-bindings/style-funcs.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"style-funcs.js","sourceRoot":"","sources":["../../src/template-bindings/style-funcs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAGH,OAAO,EACL,KAAK,EACL,eAAe,EACf,uBAAuB,GAExB,MAAM,kBAAkB,CAAC;AAC1B,OAAO,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAC7C,OAAO,EAAE,oBAAoB,EAAE,MAAM,cAAc,CAAC;AAEpD,SAAS,QAAQ,CAAC,KAAY;IAC5B,OAAO;QACL,EAAE,EAAE,CAAC,CAAC,KAAc,EAAE,EAAE,CAAC,oBAAoB,CAAC,KAAK,EAAE,KAAK,CAAC,CAAuB;QAClF,QAAQ,EAAE,CAAC,UAAU,CAAC;QACtB,UAAU,EAAE,GAAG;KAChB,CAAC;AACJ,CAAC;AAED,uBAAuB;AACvB,EAAE;AACF,6EAA6E;AAC7E,8EAA8E;AAC9E,8DAA8D;AAC9D,EAAE;AACF,6EAA6E;AAC7E,iFAAiF;AACjF,0EAA0E;AAC1E,8EAA8E;AAC9E,gFAAgF;AAChF,+EAA+E;AAC/E,wDAAwD;AACxD,EAAE;AACF,0EAA0E;AAC1E,8EAA8E;AAC9E,6EAA6E;AAC7E,8EAA8E;AAC9E,4EAA4E;AAC5E,8EAA8E;AAC9E,gFAAgF;AAChF,+BAA+B;AAE/B,SAAS,aAAa,CAAC,IAAyB;IAC9C,OAAO;QACL,EAAE,EAAE,CAAC,CAAC,IAAY,EAAE,KAAc,EAAE,EAAE,CACpC,oBAAoB,CAClB,KAAK,EACL,IAAI,KAAK,CAAC,EAAE,CAAC,IAAI,CAAC,EAAE,SAAS,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAC7C,CAAuB;QAC1B,QAAQ,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;QAChC,UAAU,EAAE,GAAG;KAChB,CAAC;AACJ,CAAC;AAED,0BAA0B;AAC1B,EAAE;AACF,sEAAsE;AACtE,yEAAyE;AACzE,yEAAyE;AACzE,oDAAoD;AAEpD,SAAS,SAAS,CAAC,IAAmB,EAAE,KAAc;IACpD,OAAO,IAAI,KAAK,CAAC,EAAE,CAAC,IAAI,CAAC,EAAE,KAAK,EAAE,CAAC,CAAC;AACtC,CAAC;AAED,SAAS,cAAc;IACrB,MAAM,GAAG,GAAY,EAAE,CAAC;IACxB,KAAK,MAAM,IAAI,IAAI,eAAe,EAAE,CAAC;QACnC,GAAG,CAAC,IAAI,CAAC,GAAG,QAAQ,CAAC,SAAS,CAAC,IAAI,EAAE,IAAI,CAAC,CAAC,CAAC;QAC5C,GAAG,CAAC,OAAO,IAAI,EAAE,CAAC,GAAG,QAAQ,CAAC,SAAS,CAAC,IAAI,EAAE,KAAK,CAAC,CAAC,CAAC;IACxD,CAAC;IACD,KAAK,MAAM,CAAC,KAAK,EAAE,SAAS,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,uBAAuB,CAAC,EAAE,CAAC;QACzE,GAAG,CAAC,KAAK,CAAC,GAAG,QAAQ,CAAC,SAAS,CAAC,SAAS,EAAE,IAAI,CAAC,CAAC,CAAC;IACpD,CAAC;IACD,OAAO,GAAG,CAAC;AACb,CAAC;AAED,gDAAgD;AAChD,EAAE;AACF,6EAA6E;AAC7E,0EAA0E;AAC1E,uEAAuE;AACvE,6EAA6E;AAC7E,sDAAsD;AACtD,EAAE;AACF,yEAAyE;AACzE,yEAAyE;AACzE,sEAAsE;AACtE,sEAAsE;AACtE,uEAAuE;AACvE,sEAAsE;AACtE,aAAa;AACb,EAAE;AACF,6CAA6C;AAC7C,gCAAgC;AAChC,mCAAmC;AACnC,EAAE;AACF,4EAA4E;AAC5E,wEAAwE;AACxE,yEAAyE;AACzE,SAAS;AAET,MAAM,aAAa,GAAiB;IAClC,EAAE,EAAE,CAAC,CAAC,IAAY,EAAE,KAAc,EAAE,EAAE;QACpC,OAAO,oBAAoB,CAAC,KAAK,EAAE,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC;IACxD,CAAC,CAAuB;IACxB,QAAQ,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;IAChC,UAAU,EAAE,GAAG;CAChB,CAAC;AAEF,oBAAoB;AACpB,EAAE;AACF,oEAAoE;AACpE,wEAAwE;AACxE,yEAAyE;AACzE,sEAAsE;AACtE,qDAAqD;AACrD,EAAE;AACF,uEAAuE;AACvE,oEAAoE;AACpE,0EAA0E;AAC1E,sEAAsE;AACtE,wEAAwE;AACxE,kDAAkD;AAClD,EAAE;AACF,+DAA+D;AAC/D,uEAAuE;AACvE,uEAAuE;AAEvE,MAAM,QAAQ,GAAiB;IAC7B,EAAE,EAAE,CAAC,CAAC,GAAW,EAAE,KAAc,EAAE,EAAE;QACnC,OAAO,oBAAoB,CAAC,KAAK,EAAE,IAAI,KAAK,CAAC,EAAE,IAAI,EAAE,GAAG,EAAE,CAAC,CAAC,CAAC;IAC/D,CAAC,CAAuB;IACxB,QAAQ,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;IAChC,UAAU,EAAE,GAAG;CAChB,CAAC;AAEF,0BAA0B;AAE1B;;;;;;;;GAQG;AACH,MAAM,UAAU,kBAAkB;IAChC,OAAO;QACL,EAAE,EAAE,aAAa,CAAC,OAAO,CAAC;QAC1B,EAAE,EAAE,aAAa,CAAC,SAAS,CAAC;QAC5B,GAAG,cAAc,EAAE;QACnB,IAAI,EAAE,QAAQ;QACd,KAAK,EAAE,aAAa;KACrB,CAAC;AACJ,CAAC"}
|
|
@@ -18,7 +18,13 @@ export interface BaseColors {
|
|
|
18
18
|
* Build a full semantic palette from base colors.
|
|
19
19
|
*
|
|
20
20
|
* Derived entries follow Textual's formulas:
|
|
21
|
-
* - `*-muted` = color blended 70% toward
|
|
21
|
+
* - `*-muted` = color blended 70% toward its opposite base role. Defined for
|
|
22
|
+
* every accent AND for the two base roles themselves
|
|
23
|
+
* (`foreground-muted` blends toward `background`,
|
|
24
|
+
* `background-muted` blends toward `foreground`) — a caller
|
|
25
|
+
* de-emphasizing body/structural text reaches for
|
|
26
|
+
* `foreground-muted` the same way it reaches for
|
|
27
|
+
* `primary-muted` to de-emphasize an accent.
|
|
22
28
|
* - `text-*` = contrast text tinted 66% with the accent color (use as
|
|
23
29
|
* foreground in muted/background-tinted contexts)
|
|
24
30
|
* - `on-*` = WCAG-correct contrast colour (black or white) for use as
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"buildPalette.d.ts","sourceRoot":"","sources":["../../src/themes/buildPalette.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,SAAS,EAAY,MAAM,kBAAkB,CAAC;AAEvD,OAAO,EAAE,OAAO,EAAE,MAAM,cAAc,CAAC;AAEvC;;;GAGG;AACH,MAAM,WAAW,UAAU;IACzB,OAAO,EAAE,SAAS,CAAC;IACnB,SAAS,EAAE,SAAS,CAAC;IACrB,MAAM,EAAE,SAAS,CAAC;IAClB,OAAO,EAAE,SAAS,CAAC;IACnB,OAAO,EAAE,SAAS,CAAC;IACnB,KAAK,EAAE,SAAS,CAAC;IACjB,UAAU,EAAE,SAAS,CAAC;IACtB,UAAU,EAAE,SAAS,CAAC;CACvB;AAUD
|
|
1
|
+
{"version":3,"file":"buildPalette.d.ts","sourceRoot":"","sources":["../../src/themes/buildPalette.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,SAAS,EAAY,MAAM,kBAAkB,CAAC;AAEvD,OAAO,EAAE,OAAO,EAAE,MAAM,cAAc,CAAC;AAEvC;;;GAGG;AACH,MAAM,WAAW,UAAU;IACzB,OAAO,EAAE,SAAS,CAAC;IACnB,SAAS,EAAE,SAAS,CAAC;IACrB,MAAM,EAAE,SAAS,CAAC;IAClB,OAAO,EAAE,SAAS,CAAC;IACnB,OAAO,EAAE,SAAS,CAAC;IACnB,KAAK,EAAE,SAAS,CAAC;IACjB,UAAU,EAAE,SAAS,CAAC;IACtB,UAAU,EAAE,SAAS,CAAC;CACvB;AAUD;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,YAAY,CAAC,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,OAAO,EAAE,IAAI,EAAE,UAAU,GAAG,OAAO,CAkCnF"}
|
|
@@ -9,7 +9,13 @@ const ACCENT_KEYS = ["primary", "secondary", "accent", "success", "warning", "er
|
|
|
9
9
|
* Build a full semantic palette from base colors.
|
|
10
10
|
*
|
|
11
11
|
* Derived entries follow Textual's formulas:
|
|
12
|
-
* - `*-muted` = color blended 70% toward
|
|
12
|
+
* - `*-muted` = color blended 70% toward its opposite base role. Defined for
|
|
13
|
+
* every accent AND for the two base roles themselves
|
|
14
|
+
* (`foreground-muted` blends toward `background`,
|
|
15
|
+
* `background-muted` blends toward `foreground`) — a caller
|
|
16
|
+
* de-emphasizing body/structural text reaches for
|
|
17
|
+
* `foreground-muted` the same way it reaches for
|
|
18
|
+
* `primary-muted` to de-emphasize an accent.
|
|
13
19
|
* - `text-*` = contrast text tinted 66% with the accent color (use as
|
|
14
20
|
* foreground in muted/background-tinted contexts)
|
|
15
21
|
* - `on-*` = WCAG-correct contrast colour (black or white) for use as
|
|
@@ -26,6 +32,14 @@ export function buildPalette(name, dark, base) {
|
|
|
26
32
|
for (const key of ACCENT_KEYS) {
|
|
27
33
|
vars.set(key, base[key]);
|
|
28
34
|
}
|
|
35
|
+
// Muted variants of the two base roles, same "blend 70% toward
|
|
36
|
+
// background" formula as the accent `*-muted` family below — every
|
|
37
|
+
// base color the palette defines gets a de-emphasized variant, not just
|
|
38
|
+
// the accents. `foreground-muted` is what a caller reaches for to draw
|
|
39
|
+
// structural/contextual text (labels, punctuation, ids) at reduced visual
|
|
40
|
+
// weight without a terminal-support-dependent SGR attribute.
|
|
41
|
+
vars.set("foreground-muted", blendRgb(base.foreground, base.background, MUTED_BLEND));
|
|
42
|
+
vars.set("background-muted", blendRgb(base.background, base.foreground, MUTED_BLEND));
|
|
29
43
|
// Surface — subtle lift from background
|
|
30
44
|
vars.set("surface", blendRgb(base.background, base.foreground, SURFACE_LIFT));
|
|
31
45
|
// Derived: muted, text-, and on- for each accent.
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"buildPalette.js","sourceRoot":"","sources":["../../src/themes/buildPalette.ts"],"names":[],"mappings":"AAAA,OAAO,EAAa,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AACvD,OAAO,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,OAAO,EAAE,MAAM,cAAc,CAAC;AAiBvC,MAAM,WAAW,GAAG,GAAG,CAAC;AACxB,MAAM,UAAU,GAAG,IAAI,CAAC;AACxB,MAAM,YAAY,GAAG,IAAI,CAAC;AAI1B,MAAM,WAAW,GAAgB,CAAC,SAAS,EAAE,WAAW,EAAE,QAAQ,EAAE,SAAS,EAAE,SAAS,EAAE,OAAO,CAAC,CAAC;AAEnG
|
|
1
|
+
{"version":3,"file":"buildPalette.js","sourceRoot":"","sources":["../../src/themes/buildPalette.ts"],"names":[],"mappings":"AAAA,OAAO,EAAa,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AACvD,OAAO,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,OAAO,EAAE,MAAM,cAAc,CAAC;AAiBvC,MAAM,WAAW,GAAG,GAAG,CAAC;AACxB,MAAM,UAAU,GAAG,IAAI,CAAC;AACxB,MAAM,YAAY,GAAG,IAAI,CAAC;AAI1B,MAAM,WAAW,GAAgB,CAAC,SAAS,EAAE,WAAW,EAAE,QAAQ,EAAE,SAAS,EAAE,SAAS,EAAE,OAAO,CAAC,CAAC;AAEnG;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,UAAU,YAAY,CAAC,IAAY,EAAE,IAAa,EAAE,IAAgB;IACxE,MAAM,IAAI,GAAG,IAAI,GAAG,EAAqB,CAAC;IAE1C,eAAe;IACf,IAAI,CAAC,GAAG,CAAC,YAAY,EAAE,IAAI,CAAC,UAAU,CAAC,CAAC;IACxC,IAAI,CAAC,GAAG,CAAC,YAAY,EAAE,IAAI,CAAC,UAAU,CAAC,CAAC;IACxC,KAAK,MAAM,GAAG,IAAI,WAAW,EAAE,CAAC;QAC9B,IAAI,CAAC,GAAG,CAAC,GAAG,EAAE,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;IAC3B,CAAC;IAED,+DAA+D;IAC/D,mEAAmE;IACnE,wEAAwE;IACxE,uEAAuE;IACvE,0EAA0E;IAC1E,6DAA6D;IAC7D,IAAI,CAAC,GAAG,CAAC,kBAAkB,EAAE,QAAQ,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,UAAU,EAAE,WAAW,CAAC,CAAC,CAAC;IACtF,IAAI,CAAC,GAAG,CAAC,kBAAkB,EAAE,QAAQ,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,UAAU,EAAE,WAAW,CAAC,CAAC,CAAC;IAEtF,wCAAwC;IACxC,IAAI,CAAC,GAAG,CAAC,SAAS,EAAE,QAAQ,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,UAAU,EAAE,YAAY,CAAC,CAAC,CAAC;IAE9E,kDAAkD;IAClD,mEAAmE;IACnE,wEAAwE;IACxE,MAAM,YAAY,GAAG,WAAW,CAAC,IAAI,CAAC,UAAU,CAAC,CAAC;IAClD,KAAK,MAAM,GAAG,IAAI,WAAW,EAAE,CAAC;QAC9B,MAAM,KAAK,GAAG,IAAI,CAAC,GAAG,CAAC,CAAC;QACxB,IAAI,CAAC,GAAG,CAAC,GAAG,GAAG,QAAQ,EAAE,QAAQ,CAAC,KAAK,EAAE,IAAI,CAAC,UAAU,EAAE,WAAW,CAAC,CAAC,CAAC;QACxE,IAAI,CAAC,GAAG,CAAC,QAAQ,GAAG,EAAE,EAAE,UAAU,CAAC,KAAK,EAAE,YAAY,EAAE,UAAU,CAAC,CAAC,CAAC;QACrE,IAAI,CAAC,GAAG,CAAC,MAAM,GAAG,EAAE,EAAE,WAAW,CAAC,KAAK,CAAC,CAAC,CAAC;IAC5C,CAAC;IAED,OAAO,IAAI,OAAO,CAAC,IAAI,EAAE,IAAI,EAAE,IAAI,CAAC,CAAC;AACvC,CAAC"}
|