Allow "Full Width" toggle to save per file

[telekrex]

What problem would this solve?

I use Markdown sometimes in full width, when I have tables, sometimes in the regular narrow version. My preference on this is entirely based on the file I'm working with, and there is often re-occuring revisits.

What would you like?

The option is already toggle-able which is nice, but if it simply saved that state for that file, it would eliminate constantly toggling.

Has another app got this right?

Not to my knowledge. I wanted this in Obsidian and I don't think it had it.

Which platform is this for?

All platforms

Your Markpad version and how you installed it

No response

[PathGao]

Reasonable ask, and the toggling you describe is real. It is more expensive than it looks, though, so it needs a maintainer call before anyone writes code.

Full Width is one app-wide setting today. Per file means Markpad has to start remembering things about individual files, which it does not do anywhere yet, and that memory has to stay correct while several windows share it. Four behaviour questions have to be answered first: what a new unsaved file with no path on disk uses, whether exports follow the per-file width or keep the global one, how many files are remembered before the oldest is dropped, and whether two windows showing the same file must agree.

Implementation notes — nothing you need to read

Checked against master @ 7ee94ac.

• preview.fullWidth is a single localStorage key. settings.svelte.ts holds the $state, togglePreviewFullWidth() and the persistence entry with its legacy isFullWidth fallback; MarkdownViewer.svelte reads the value in six places (the getPreviewContentWidth derived, the export payload, the preview-width-narrower/wider reset, two TitleBar props, and the .markdown-body.full-width class). A per-file override has to replace all six at once, or the preview and the export disagree.
• The settings persistence framework cannot hold the override table. It runs one $effect per key and read must touch exactly one field, so a whole-table field would be republished from each window's in-memory snapshot — the multi-window clobber updateStoredRecentFiles exists to prevent. The table needs that same read-modify-write, read-back and attempt-cap treatment from recentFiles.ts, plus a storage listener to fold in sibling windows. singleImplementationConvention.test.ts already names a bare setItem on preview.fullWidth as the defect.
• Renames have to follow the file, the way renameRecentFile does, and the table needs a cap or it grows without bound.
• Rough size: a new util of ~120–150 lines at this repo's commenting density, ~55 lines across the store and the viewer, one new multi-window spec on the order of recentFilesMultiWindow.test.ts (264 lines), and five existing shape tests to update (previewWidth, exportContentWidth, settingsPersistence, shortcutRegistry, singleImplementationConvention). Call it 400–550 lines over 7–9 files.
• Frontmatter is the other shape: a line in the file instead of a table in the app. No new store, travels with the file across machines, but it edits the user's content.

[PathGao]

#840 handles the table case another way. Instead of remembering the width per file, the narrow view now lets a wide table grow into the side margins, centred on the text, while paragraphs keep the narrow width. A table that already fits does not move, and one wider than the window still scrolls inside itself.

Limits:

• Only tables at the top level of the document. A table inside a list item, blockquote, callout or footnote stays in the column and scrolls.
• While the outline floats in the margin, a table stops at the outline's edge, so it gets less room.
• HTML and PDF export keep tables at the column width.
• Code blocks and diagrams are unchanged.

Remembering Full Width per file is not planned for now. It would change how and in what format Markpad stores its data, and that whole pipeline would have to change with it, which is not stable enough yet. If you switch to full width for something other than tables, tell us what it is and we can look at that case.

[telekrex]

Sounds like a better solution & looking forward to seeing it in action soon

[PathGao]

can you check it on 2.8.0 and see if it is good enough？

[telekrex]

just tried it out and yes this works fine! good work & thank you