What's the editor, debugging, and error experience?

Why it matters

Editing a language your editor doesn't understand feels like a step backward, and early on that was a fair complaint. It isn't anymore: the extension gives you the modern niceties, and the errors are written to teach, not just to reject.

See it

Every diagnostic carries a stable code, a one-line fix, and often the design reason. glyph --explain prints the long form for any of them:

[E0203] the `?` operator propagates error type `HttpError`,
        but this function returns `Result<_, string>`
   ╰─ Help: map the error first, e.g. `.map_err(...)`,
      so its `E` matches the function's.

We tightened the messages exactly where agents and newcomers stumble most: writing if now points you at match instead of a generic “unexpected token,” and a wrong argument count, a non-exhaustive match, or a mistyped variant each get their own coded, fixable error.

Type errors that only the TypeScript back-end can catch used to point at the generated .ts. Now they're mapped back onto your .glyph — same ariadne caret, same stable code — so a tsc error reads like a native Glyph one.

Debugging, honestly: you debug the emitted TypeScript with the tools you already use — Node's inspector, browser devtools, your IDE's JS/TS debugger. Every build now ships a standard v3 source map beside each .ts (with the Glyph source embedded), so a debugger or a bundler that chains maps steps back into your .glyph line numbers. (One honest edge: glyph run's own crash stack still prints .ts lines, because tsx doesn't chain the map through its transform — remapping that stack is next.)

And for the agent in the loop: glyph build --json emits every diagnostic as structured JSON — a stable code, severity, message, file, and 1-based line/column range, plus the help and note — including tsc errors mapped onto your Glyph source. An agent reads and acts on them directly instead of scraping terminal text.

Not everything is a hard error. Glyph has a warning tier that flags dead weight without failing the build: an unused import (E0106), an unused let (E0107, exempting names led by _), and unreachable code after a return/break/continue (E0108). These keep a module honest — a dead import is exactly the kind of greppability noise that makes a reader hunt for a dependency the code doesn't really have. Warnings surface in the same rendered and --json output, marked by severity, and still emit TypeScript.