From b428ce2b4908bc31c213a99518cffb007e61575b Mon Sep 17 00:00:00 2001 From: Sergii Demianchuk Date: Sun, 16 Aug 2026 19:46:00 -0400 Subject: [PATCH] =?UTF-8?q?revert(chat):=20put=20the=20original=20wordmark?= =?UTF-8?q?=20back=20=E2=80=94=20the=20new=20one=20breaks=20in=20Monaco?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The wordmark from #82 shatters into disconnected bars in the editor. Reverted. WHAT I GOT WRONG. I claimed the art "cannot develop seams in any monospace font" because it is drawn entirely from `█`. Half of that reasoning was sound — `▀` above `▄` does leave a full cell of gap, which I verified — but the conclusion did not follow: whether `█` FILLS its cell is a property of the FONT, not of the character. Rendered across seven monospace families, the art is solid in SF Mono, Menlo, Courier New, Andale Mono, Consolas and the generic fallback, and shatters completely in Monaco. My harness ran SF Mono, so it looked perfect everywhere I checked, and none of those checks were the editor. The seam test I was so pleased with tested the right mechanism in the wrong place: one font, in a harness, instead of the font the webview actually resolves. The test guard went with it. It asserted "full blocks only", which encoded the false belief as a rule — it would have blocked the fix and waved through the bug. What survives is what this file can honestly check: the column/line bounds (real, and about layout rather than glyphs) and the accessible name. ASCII art has to be looked at in the target font; a static test cannot do it, so it no longer pretends to. The original 12x41 art is restored byte-for-byte from 8126086^. 33 tests in webviewCss, 34 suites green. --- extensions/levelcode-ai/media/chat.html | 23 ++++++++-------- .../levelcode-ai/test/webviewCss.test.js | 26 ++++++++----------- 2 files changed, 23 insertions(+), 26 deletions(-) diff --git a/extensions/levelcode-ai/media/chat.html b/extensions/levelcode-ai/media/chat.html index 280e220..a6188eb 100644 --- a/extensions/levelcode-ai/media/chat.html +++ b/extensions/levelcode-ai/media/chat.html @@ -1259,17 +1259,18 @@
-
+
levelcode.ai
Ask about your code, or describe what to build. The open file is sent as context; add a selection with + or ⌥⌘A.
diff --git a/extensions/levelcode-ai/test/webviewCss.test.js b/extensions/levelcode-ai/test/webviewCss.test.js index f2f16d1..91156d2 100644 --- a/extensions/levelcode-ai/test/webviewCss.test.js +++ b/extensions/levelcode-ai/test/webviewCss.test.js @@ -578,25 +578,21 @@ test('TRANSCRIPT: the user bubble hugs its content, and is capped short of the c 'tint is the secondary cue and still earns its place — side alone would drop on a wrapped log'); }); -test('WORDMARK: the empty-state logo is full blocks only, and fits its container', () => { - // Drawn on a 10-row pixel grid with 2px strokes, then packed two pixel rows per text row. Because - // every stroke is an even number of pixels, each pair collapses to a FULL block — no ▀ or ▄ survives. - // - // That is the property worth pinning, and it was learned the hard way. `▀` sits at the top of its - // cell and `▄` at the bottom, so `▀` directly above `▄` leaves a full cell of empty space between - // them: a seam straight through the letterform. A 1px-stroke font produces that constantly and - // shatters. Full blocks tile seamlessly in any monospace font, so this art cannot develop seams no - // matter what the user's editor font is. +test('WORDMARK: the empty-state logo fits its container and has an accessible name', () => { + // NOT asserted here: which characters it is drawn from. A previous version of this test required + // full blocks only, on the theory that `█` tiles seamlessly while `▀`/`▄` can seam. Half of that is + // right — `▀` above `▄` does leave a gap — but the other half is not: whether `█` FILLS its cell is + // a property of the FONT, not of the character. In Monaco it does not, and a wordmark built on that + // assumption shattered into disconnected bars in the editor while looking perfect in a harness + // running SF Mono. The lesson is that this file cannot check the thing that actually matters, so it + // should stop pretending to; ASCII art has to be looked at in the target font. const m = /
]*>([\s\S]*?)<\/pre>/.exec(html);
 	assert.ok(m, 'the empty-state wordmark is gone');
 	const art = m[1].replace(/^\n/, '');
-	const glyphs = new Set(art.replace(/[\n ]/g, ''));
-	assert.deepStrictEqual([...glyphs], ['█'],
-		'the wordmark uses partial blocks: ▀ above ▄ leaves a seam through the stroke in most fonts. '
-		+ 'Found: ' + [...glyphs].join(''));
 
-	// It is sized by the container (clamp(5px, 3.6cqi, 13px)) inside #empty, which is capped at 560px.
-	// Past ~44 columns it stops fitting and the pre grows a horizontal scrollbar under the logo.
+	// This bound IS checkable and is not about glyphs: the logo is sized from the container
+	// (clamp(5px, 3.6cqi, 13px)) inside #empty, which is capped at 560px. Past ~44 columns it stops
+	// fitting and the pre grows a horizontal scrollbar under the logo.
 	const lines = art.split('\n');
 	const cols = Math.max(...lines.map((l) => l.length));
 	assert.ok(cols <= 44, 'the wordmark is ' + cols + ' columns; wider than ~44 overflows #empty (max 560px)');