Add draggable table column resizing

[aseelye]

Adds draggable column resizing for Markdown tables in the live preview, with widths persisted outside the Markdown file in Application Support. Includes renderer and persistence tests.

[schuyler]

Thanks for this — a lot of careful work, and the non-persistence parts are well done: the token-gated x-macdown-table-layout:// bridge cleanly mirrors the existing checkbox pattern, the drag UX is solid, and the Save-As tests are thorough. I'd like to land table resizing.

My main concern with this PR is the persistence model, not the feature. The path-keyed table-layouts.json under Application Support adds a third state-persistence pattern to the app — today we only have NSUserDefaults and writing back into the Markdown source (the checkbox toggle, #269). A path-keyed sidecar is a format we'd have to support forever, and it's fragile: widths orphan on rename/move, the header-hash resets them when a heading is edited, the global file races across open documents, and entries never get pruned.

How would you feel about persisting column widths in the document itself, using the table's delimiter row? A pipe table's delimiter dashes are ignored by the renderer (only colons matter), so we could co-opt dash count as a proportional width:

| Name | Description                   | Qty |
| ---- | ----------------------------- | --- |

→ apply <col style="width: N%">, and on drag-release rewrite the delimiter line in the source via the same path the checkbox toggle already uses. That keeps everything in one pattern we already have: no sidecar, no path-keying, no GC — the widths are the file, so they travel with it and degrade gracefully (other renderers just see a normal table). The tradeoff is widths become proportional rather than pixel-exact, which I think is the right call for a reflowable document anyway.

I confirmed our renderer cooperates: against our pinned hoedown 3.0.7, dash count above the minimum has zero effect on output (--- vs a 40-dash run are byte-identical). The only constraint is a floor of ≥3 chars per cell, so the recompute just clamps each cell to ≥3 dashes.

You'd keep essentially all the front end — handles, CSS, bridge, colgroup logic; only the persistence half changes. Happy to take that piece on myself if you'd rather not redo it.

(Separately: the baseline #432 regression is handled in #440, so this PR can focus purely on resizing.)

---

Generated by Claude Code

[aseelye]

Putting the formatting in the document would make it incompatible with prior versions of macdown and just about every other markdown editor out there. A local store of this data in a user folder could suffice, or if they didn't want that, to just resize as needed each time it's opened. The former would be preferred though.

[schuyler]

Putting the formatting in the document would make it incompatible with prior versions of macdown and just about every other markdown editor out there. A local store of this data in a user folder could suffice, or if they didn't want that, to just resize as needed each time it's opened. The former would be preferred though.

I like the idea behind this feature and I agree that it should be persistent. I didn't realize just what a pain it was to have the fixed column widths.

What do you mean when you say "incompatible with prior versions of macdown and just about every other markdown editor out there"? Aside from doing a quick spike in Hoedown to make sure that the idea would work, I only did a cursory search but I am unaware of any Markdown parsers that care how many dashes are present in that row. If I'm missing something, please let me know!

Even beyond my vague concerns about long term maintenance burden, I'd love it if we could find a solution that doesn't break if a user copies the file to a different computer, or potentially, a different folder on the same computer.

[jclark-dot-org]

As an observer who came here to report a table rendering issue (see image), +1 for the idea, and +1 for storing in the markdown text. I'd much rather see the unrendered text with sensible column sizes anyway.

This is what my raw MD looks like (generated by Claude); it's fine if you only plan to render, but Markdown was designed to be readable without rendering, and minimal-width-columns are anything but.

| Object | Status | Gating for me |
|---|---|---|

[aseelye]

Yeah, it's a good idea. I'm not sure if I should build in the things like alignment/justification as the Github Flavored Markdown spec allows. I'd personally say 'yes', with an option in the Settings dialog to allow/disallow it, but that might turn into biting off a lot more than would be appropriate.

[schuyler]

@aseelye I'm happy to take over where you've left off -- I certainly don't want to hand you a bunch of extra work you didn't originally sign up for, just because I had a different idea of where this ought to slot in architecturally. You've gotten the ball rolling, and I'm happy to get this extremely valuable feature to a place where I'd be glad to merge it. Please let me know whether you'd prefer that or to finish it yourself?

[aseelye]

To the contrary, please do. I'm sure whatever you patch it would fit more cleanly. FWIW I did like the idea of jclark's to insert the additional hyphens instead of a local datastore of file settings, will be more portable and better for group collabs. Also might want to consider using the github markdown extensions down the road for increased formatting options.

[schuyler]

Taking this over per the discussion above — proceeding with the in-document, delimiter-row persistence model.

Thanks again @aseelye. I'm keeping your front end essentially intact (the drag handles, export.css, the token-gated x-macdown-table-layout:// bridge, and the <colgroup>/<col> injection) and reworking only the persistence half, as we discussed. Here's the interpretation I'm building to — corrections welcome on the PR that will supersede this one:

Persistence model. Column widths live in the document, encoded as the dash counts of the pipe-table delimiter row (| ---- | -------- | --- |). At render time each column's width comes from its share of the row's dashes → <col style="width:N%">. On drag-release the delimiter line is rewritten in the Markdown source with recomputed dash counts. Widths are proportional, travel with the file, and degrade gracefully in other renderers. The table-layouts.json sidecar and all its supporting code are removed.

Behavior / constraints:

• Each cell clamps to ≥3 dashes (hoedown 3.0.7's floor; above it, dash count has zero effect on rendered output — confirmed).
• Alignment colons (:---, ---:, :--:) are preserved on rewrite; only the dash channel carries width.
• A table that's never been resized renders at natural widths (no explicit <col> widths) — "never resized" and "resized to equal" are intentionally indistinguishable in-source.
• Only the delimiter line changes; the rest of the table text is left untouched.

Explicitly out of scope (candidate future issue): the GFM alignment/justification toggle — @aseelye raised it and flagged it as possible scope creep; agreed, deferring. The #432 natural-width regression is handled separately in #440, not here.

Open items I'll carry into the PR: the exact source-rewrite mechanism (the checkbox-toggle path I named does a whole-document text swap; a targeted, undoable edit may be preferable for selection/undo safety — I'll decide against the actual code), and correct-table targeting when a document holds multiple tables (index/hash mapping between the DOM and the source).

Tests that asserted the sidecar behavior are removed or retargeted; the bridge, token-gate, CSS, and export tests are kept. @aseelye's original commit is preserved with authorship intact.