Hazel reports · ^report(19) · 2026-10-19

The Hazel UI draws syntax as tiles on 22 of 39 surfaces, but only 6 take a caret

Cyrus asked for two things on 2026-10-16: livelits' model views as read-only tiles, with the selection and right-click menu tiles have in the editor, and the explainer's examples as read-only tiles too. Both asks assume some views print syntax as text. Matthew asked for the whole picture: every place the Hazel UI shows a term, pattern, type or value, and how it draws it. For the meeting with Cyrus on 2026-10-21 (^ticket(389); this report is ^ticket(393)).

Four ways to draw syntax

Hazel's editor draws code as tiles: each token a span placed by the editor's layout, with holes, grout and indentation drawn the editor's way. The same renderer, Code.view, is called in many places besides the editor. What differs between those places is what comes with it: a zipper (the edit state with a caret) and an input handler, or nothing. That gives four kinds of surface, told apart here by what a click does, not by how the page looks:

A surface is classed by what it does, not by its classes in the page. The Projectors card's header is a single element with the token class holding a printed string, so it looks like a tile but counts as text. The explainer's examples sit in an editor element that takes focus when clicked, but no caret appears and no menu opens, so they count as tiles to look at.

Every surface, by kind

Each row names a surface as someone using Hazel meets it, then gives what syntax it shows, what a click does, the code that draws it (paths under src/ on #2635 at b44bb9c50f), and whether it was checked in the running app or traced in the code.

Tiles you edit: 3

Only the places where a person writes code.

Read-only tiles you can select: 3

Read-only, with a caret. The revealed model is the one surface with everything tiles offer in the editor except edits: Perform refuses typing inside it. The stepper and the result show a caret but have no menu, and the stepper's caret does not move the inspector.

Tiles you can only look at: 16

The largest group of tiles. Each is a Code.view of a segment, built for the view and thrown away, so there is no zipper to put a caret in. Γ is the costliest: it prints every type in the context whole, the prelude's included, so it draws 6,802 tiles for a four-line program.

Plain text: 17

Strings printed from syntax. Some are text by design: a livelit's head and params lines are inputs, to be edited as text. Some are text to save space (the Projectors card's header, the outline), and some because they are written as prose (inline code in explanations and tutorial prompts).

Debug-only

Two more views print syntax as text, but only for debugging. They are not counted above.

• The debug sidebar, raw mode (AST dumps): None. DebugSidebar.re:180-397, 599
• The debug console (F3 to F9) (exp, value): Browser console only. DebugConsole.re:17-92 ProbeText.re:70, 154

What this means for the open asks

Livelits' model views as read-only tiles (^ticket(387)). The model revealed with a livelit's eye already is what Cyrus asked for: read-only tiles with a caret, selection and the right-click menu. The two other views of a livelit's syntax are tiles as well. A refractor's splices and the Projectors card's splices both go through default_render_splice, which calls Code.view, so they are tiles to look at, without selection. Only the card's header (^flag(true)) is text. So the work is to give those two the revealed model's selection, not to turn text into tiles. (An earlier reading, the same morning, took default_render_splice for text; the code and the app both say tiles.) The head and params lines stay text inputs, by Matthew's call.

The explainer's examples (^ticket(388)). They are tiles: each example is a cell editor with ~locked=true, drawn read-only, with its value under it. Clicking one gives it focus and nothing else, so it shows no caret, no selection and no menu. What is text in the explainer is the inline code in its prose (such as true and false in the boolean literal's explanation), and any fenced block that is not marked hazel or does not parse.

What next

1. Give the refractors' and the Projectors card's splices the revealed model's read-only selection: caret, Shift+Arrow and the right-click menu (^ticket(387)). Decide whether the card's header stays text.
2. Make the explainer's examples selectable read-only tiles, and draw its inline code as tiles where the snippet parses, as fenced hazel blocks already are (^ticket(388)).
3. Build one read-only, selectable tile view, from the revealed model's, and use it wherever selecting helps: the inspector's full view, Γ, probe values and the program's value.
4. Give the stepper and the evaluation result Hazel's right-click menu, and let the stepper's caret move the inspector, as the result's does.
5. Find out why Γ costs what it does: 6,802 tiles for a four-line program, because every prelude type is printed whole (^ticket(396), where opening Γ on the Scenes slide froze the browser).
6. Reproduce by hand a stale value seen once during this survey: on #2635, after switching from a Documentation slide to Scratch and pasting a program (by a scripted paste), the program's value showed the previous slide's value, marked stopped, until the page was reloaded.

How this was put together

• The build: #2635 (integration/livelits-modular-editors) at b44bb9c50f, built with the dev profile and served locally. Dev's evaluation result was checked on #2698 at 4c9cc34d3b (dev with Γ's long types), since #2635 draws a program's value differently.
• In the app (16 surfaces): in the Claude desktop app's browser pane, on Documentation › Livelits › Overview, Documentation › Probes, and small programs in Scratch. For each surface: how many token elements it draws, whether a click puts a caret in it or moves the inspector, and whether a right-click opens Hazel's context menu. The control was the editor, where right-click opens the menu (Select term, Cut, Copy, Paste, Add probe).
• In the code: a read-only sweep of src/web and src/haz3lcore/projectors for every view that draws syntax: the Code.view family, CodeEditable, CodeSelectable, and every printer (Printer.of_segment, Segment.to_string, Typ.pretty_print, text_code), with each call traced to the surface a person sees. Printing that is never shown (copying to the clipboard, measuring widths, comparisons, the agent's model context) is left out.
• Not covered: the exercise modes and the coding agent were traced in the code only, and hover cards were not surveyed. Each row of the table says how it was checked.
• The data: in this page's <script type="application/json" id="report-data"> element and in 019/data/surfaces.json; the page is made by 019/drivers/gen019.py.
• #2635 is Matthew Hammer's branch, made and kept with Claude. Most of the views surveyed here come from dev, and are the Hazel team's work.