1.2.53

Bump to v1.2.53 — Two switches that read as two switches

The tab bar's Read/Edit and Visual/Raw toggles sat side by side as four
same-looking squares, and after Read took the eye, Visual was an eye as well —
two identical icons a few pixels apart meaning different things.

Each toggle is now drawn as a switch: a faint track with the active side
raised as its thumb (white in light mode, a lighter tint in dark, where the
page background is too close to the tab bar to read as raised). A thin rule
separates the pair, so it's clear which two icons belong together. Visual
takes Lucide's `type` glyph — formatted text — leaving the eye to mean Read
alone; Settings and the command palette follow suit. Both toggles now carry a
tooltip naming the current mode and the shortcut.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1.2.52

v1.2.52

Bump to v1.2.52 — Read mode, code that doesn't wrap, and every open f…

1.2.51

v1.2.51

Bump to v1.2.51 — Tag a fence from the visual editor, and a preview t…

1.2.50

v1.2.50

Bump to v1.2.50 — Middle-click closes a tab, and the outline reaches …

1.2.49

Bump to v1.2.49 — Syntax colors stay readable in light mode

Headings, bold and inline code were painted #f87171 — tailwind red-400 —
regardless of theme. That colour is built for a dark background; against the
white light-mode page it lands at about 2.6:1, well under the 4.5:1 that
normal-size text needs, and a coloured heading came out fainter than the plain
black one beside it. Turning the "syntax colors in visual editor" setting on
made the document harder to read, which is the opposite of the point.

The two themes need genuinely different reds, not one red at two opacities, so
the colour moves behind a --syntax-accent token defined per theme in main.css:
red-700 (#b91c1c, ~6.5:1 on white) in light mode, and red-400 unchanged in
dark. The tinted inline-code background and its border get the same treatment.

Applied to the raw CodeMirror editor as well as the visual one — the setting
promises the visual editor will "match the raw editor", and the raw editor was
drawing the identical washed-out red on the identical white background. That
means the token has to work from inside a CodeMirror theme: it does, since
those compile to ordinary CSS rules and a custom property inherits from <html>,
so the colour re-resolves on its own when the theme flips.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1.2.48

Bump to v1.2.48 — Diagram labels keep their last character

A node label written as `name<br/><i>path/</i>` came out with the path cut short:
"resume-builder/resume-dr", the trailing slash gone. v1.2.47 already waited for
Inter before rendering, on the grounds that mermaid measures a label and then
draws the box around the measurement, so a font arriving between those two steps
leaves the box too narrow and a `<foreignObject>` clips the overflow. That was
right, but it waited for one face. A label is not one face: `<i>` and `<b>`
inside it pull in the italic and bold cuts too, and the app never draws in Inter
Italic anywhere else, so that face was not merely late — it had never loaded at
all. Measured in the fallback, drawn in the real thing, three pixels short.

Wait for all four cuts a label can use, and hand `document.fonts.load` the
diagram's own text while doing it: Inter arrives from @fontsource split across
unicode ranges, and the em dash in "resume-builder — the monolith" lives in a
different subset from the ASCII either side of it.

The wait is now capped rather than open-ended. A window that isn't compositing
can leave both `fonts.load` and `fonts.ready` pending for as long as it stays
that way, and the dialog would sit on its spinner with no way out; after two
seconds it renders regardless. And `foreignObject` no longer clips, so a label
that still doesn't fit overhangs its box instead of losing its tail — untidy,
but readable, which silently dropping the last two characters is not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1.2.47

v1.2.47

Bump to v1.2.47 — Preview mermaid diagrams, copy any code block, unsa…

1.2.46

Bump to v1.2.46 — The visual editor stops adding escapes it doesn't need

Escaping used to be an all-or-nothing question asked per text node: if any part
of a line was markup, every `` ` * ~ [ ] _ `` in it got a backslash. A line that
merely looked like it might open a block took the same conservative path, even
in the middle of a line where a `*` was never a bullet.

Ask it per character instead. Start from the candidate with no escapes at all
and run it through the same inline parser the editor loads files with; if it
comes back as one flat run of text identical to the input, write it verbatim.
If it doesn't, add one backslash — leftmost first — and ask again, then take
each one back out to see whether it was needed. `a[b](c)` gets one escape
instead of two, a literal `**bold**` two instead of four. Block-opener escaping
is now a separate question, asked only where prosemirror-markdown says the write
really is starting a block, and it backslashes the marker alone. Link labels are
probed as link labels, so `[see foo_bar](url)` keeps its underscore.

The louder half of the bug was elsewhere. Editing a `*`-bulleted item made the
merge write it back as `- item` next to its untouched `* sibling` — two lists,
not one — so the merge failed its own re-parse check and the whole document fell
through to strict escaping. A rewritten list item now keeps the file's own
marker, which is what kept the fallback from firing in the first place.

Measured over 2400 adversarial strings: documents gaining an escape drop from 71
in 600 to 2, and across a corpus of ordinary prose — `highlights[]`,
`{{> _shared/x }}`, `src/lib/foo_bar.ts`, `C:\Users\...`, tables, task lists,
nested lists — to none. Opening round-trip.md and flipping to raw is still
byte-identical; editing a heading and a list item now leaves `*` bullets, `1)`
numbering, the five-blank-line run and the blockquote's bare `>` exactly as they
were.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1.2.45

Bump to v1.2.45 — Copy “name” as Pathname in the sidebar and tab menus

Finder's Option-key entry, in the app's own menus: files and folders in the
sidebar (right-click and the "…" button), the section headers, and a tab's
right-click menu all offer `Copy “name” as Pathname`, wording and curly quotes
included. Long names are elided so a deep file can't stretch the menu.

Copies go through Electron's clipboard over IPC rather than
`navigator.clipboard`, which needs a focused document and a granted permission
— neither guaranteed when the write is fired from a context menu. The command
palette's existing "Copy file path" and "Copy markdown" now take the same
route, and copying a path confirms with a toast, since the clipboard gives no
feedback of its own and a silent no-op looks identical to a failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1.2.44

Bump to v1.2.44 — Any placeholder that names a file is a link

Click-through was limited to `{{> path}}` imports, but a plain `{{revision}}`
sitting next to a revision.md is just as much a reference to that file — and
that's the common case inside a prompt folder, where the sibling file is the
thing you actually want to jump to.

A placeholder now links when it resolves to a file: same folder first, then up
the tree, then the sidebar roots. Imports stay clickable even unresolved (the
toast names what's missing); plain placeholders link only on a real hit, so
ordinary substitutions like {{product_name}} stay undecorated.

Resolution is synchronous, off an index built from the folder tree the sidebar
has already walked — decorations can't wait on the filesystem — and each
editor resolves against its own file rather than whatever tab is active, which
also fixes references in a background pane or a diff side.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>