Option to use one window size for every file

[vmlrodrigues]

I filed this thinking Mud didn't remember window size. It does — per file,
since 4.0.0 — so my original description was off. Rewriting it to describe
what I'm actually after.

Per-file sizing works nicely if you want different documents at different
sizes. I'm the other sort: I keep everything filled to the screen. With
per-file memory that means filling each document the first time I open it, and
there are always new documents, so it never quite settles.

What I'd love: an option to use the same window size for every file — the
size of the last window I sized — as an alternative to a size per file.
Per-file would stay the default; I'd just switch it once and forget about it.

A smaller, separate thing: a file Mud hasn't opened before appears at a
fixed 860×740 rather than the size I last used. That one might be worth
changing whichever mode is on, since there's nothing to restore for that file
and the last size I chose is a closer guess than a constant.

One incidental benefit, if it appeals: in "same size for every file" mode Mud
would only need to keep one window frame, rather than one per file opened.

I've had a go at writing both up as a plan document, in case it's useful —
I'll add it in a comment below. I realise the first part is a product call
rather than a bug, and I'd completely understand if it's not something you
want in the app. The second part stands on its own either way.

[vmlrodrigues]

Here's the plan document, in case it's useful — folded up below so it doesn't
swamp the thread. Happy to send it as a file instead if you'd rather have it
as a document.

Two changes, the second much smaller than the first:

• A "New window size" picker in General — "Remembered for each file"
  (today's behaviour, and still the default) or "Same as the last window you
  used".
• A better fallback for a file Mud hasn't seen before — the last size
  used, rather than the fixed 860×740. That one applies in both modes.

For the mechanism it suggests a second Cocoa autosave name shared by all
document windows, sitting alongside the per-file ones. The seed then comes
back through setFrameUsingName, which carries the tiling state macOS stores
in the frame value and constrains the frame to the current screen — so no new
preference is needed for the frame itself, only for the picker.

I went back through the phase 4h notes to make sure none of it undoes what
that fixed: closing one window still can't change another file's remembered
size. In "same size for every file" mode the per-file autosave name simply
isn't set, rather than set and overridden, so those keys are frozen instead of
flattened and switching back finds every file as it was.

There's a verification section at the end with steps for both modes, including
that regression check. The evidence section has the actual defaults keys I was
reading while working it out, in case any of it is handy.

All just a suggestion — you know the app and I don't, and I'd completely
understand if the picker isn't something you'd want to carry. The fallback
change stands on its own if the rest doesn't appeal.

Plan: How Window Size Is Remembered (click to expand)

Plan: How Window Size Is Remembered

Status: Proposed — raised as issue #21

Context

Since v4.0.0, each file keeps its own window size and position. Reopen a file
and it comes back as you left it, tiling included. For someone with a wide
reference document and a narrow notes file, that is exactly right.

Someone who wants one size for everything has no way to ask for it.

This adds a setting, chosen in General, with two answers: keep a size per
file, or use the same size for every file. Per-file stays the default.

It also changes what happens when there is nothing to remember yet. A file Mud
has never opened appears at a fixed 860×740, where the last size the user
chose would be a closer guess.

Why per-file exists

Worth knowing before changing anything around it. Phase 4h replaced a single
global window-frame preference with setFrameAutosaveName, keyed by file
path, because the global slot let one closing window overwrite another's size.
Its notes are explicit that per-file memory was a by-product:

One behavior change beyond the bug fix: because the autosave name is keyed
by file path, reopening the same file now restores that file's own last
frame rather than whichever window closed most recently — a bonus follow-on
of fixing the overwrite bug, not a separate design goal.

The decision point allowed either autosave "or standard cascading". Autosave
won, and per-file memory came with it. Nothing here disturbs the bug it fixed:
closing one window still cannot change another file's saved size.

What it doesn't cover

A file Mud hasn't seen falls back to a fixed size. There is nothing to
restore for it, so the constant just above the autosave call stands in:

window.setContentSize(NSSize(width: 860, height: 740))
window.center()

That is a reasonable default and it has to be something. The last window the
user sized is simply a better guess than a constant, and Mud already has it.

There is no way to choose one size for everything. Per-file memory is not
erratic — every file remembers its own size, always. But nothing on screen
says which files Mud has seen, so the next open is hard to predict without
knowing the rule. And improving the fallback does not help here: it only
touches files Mud has never opened, so a file once made small still reopens
small.

That is a fork, not a defect. folder-open-behavior answered the same shape
of question — "the right answer for a flat pile of documents and the wrong one
for a docs tree" — by letting the user pick. This does the same.

Evidence

Mud 4.2.0 (21) on macOS 26.6.2. A file opened once and left alone:

"NSWindow Frame document-window:…/Doc/Examples/feature-showcase.md"
    = "470 309 860 740 0 0 1800 1130"

860×740 at x=470, and (1800 − 860) / 2 = 470 — the constant, centred.

A file that has been filled:

"NSWindow Frame document-window:…/Doc/Plans/2026-02-mud-app.md"
    = "0 66 1800 1064 0 0 1800 1130
       {\"tilingState\":{\"tilingPosition\":9, …}}"

Filling a window is macOS tiling, and macOS stores the tiling state in the
same value. So a filled file reopens genuinely tiled, not just at that size.
Any replacement has to preserve that blob.

What the user sees

General settings gains a picker, "New window size":

• Remembered for each file — today's behavior, and the default
• Same as the last window you used

Below it, in the secondary style the pane's other pickers use:

Each document can keep its own size and position, or every document can open
at the size you last used. Remembering each file means Mud keeps a note for
every document you open; the last-used size needs only one.

The second sentence earns its place. The two modes differ in what Mud stores,
not only in how windows open, and that should be visible at the point of
choosing.

In both modes, a file Mud has not opened before appears at the size of the
last window the user sized. Only the very first document on a fresh install
gets 860×740.

Changing the setting affects windows opened afterwards. Windows already on
screen are left alone.

Design

The fallback

Document windows share one extra autosave name alongside their per-file ones:

private static let lastFrameName = "document-window-last"

Every document window writes to it when the user finishes a resize, moves the
window, or closes it. Seeding a new window is then Cocoa's own call:

private func seedFromLastUsed(_ window: NSWindow) {
    if !window.setFrameUsingName(Self.lastFrameName) {
        window.setContentSize(NSSize(width: 860, height: 740))
        window.center()
    }
}

Using Cocoa's mechanism rather than storing an NSRect in MudPreferences
gets three things free. The tilingState blob is carried verbatim, so a
seeded window is genuinely tiled. The frame is constrained to the current
screen, so a size captured on an external display does not open a window off
the edge of a laptop. And no preference key is needed for the frame at all.
It also matches what phase 4h chose: "Cocoa now owns this storage under its
own per-name defaults key, outside MudPreferences."

The setting

MudPreferences gains one key, window-size-behavior, backed by an enum
alongside FolderOpenBehavior:

public enum WindowSizeBehavior: String, CaseIterable, Sendable {
    case perFile  = "per-file"
    case lastUsed = "last-used"

    public var label: String {
        switch self {
        case .perFile:  return "Remembered for each file"
        case .lastUsed: return "Same as the last window you used"
        }
    }
}

At window creation, after content and toolbar setup — the ordering the
existing comment protects:

let name = Self.frameAutosaveName(for: url)
switch MudPreferences.shared.windowSizeBehavior {
case .perFile:
    // This file's own size if it has one, else the last-used size.
    if !window.setFrameUsingName(name) { seedFromLastUsed(window) }
    window.setFrameAutosaveName(name)
case .lastUsed:
    // Always the last-used size. No autosave name is set, so per-file
    // sizes are neither read nor written while this mode is on.
    seedFromLastUsed(window)
}

Under .lastUsed the autosave name is not set at all, rather than set and
then overridden. An override would let Cocoa write the shared size back under
each file's key and flatten every file's memory to one value. Leaving it unset
freezes those keys, so a user who tries .lastUsed and switches back finds
every file as they left it.

That also means .lastUsed stores one window size in total, however many
documents are opened. .perFile accumulates one key per file ever opened, and
never removes any (see the follow-up). So the setting decides how much Mud
remembers as well as how windows open.

Files changed

1. Preferences/Sources/WindowSizeBehavior.swift — new enum.
2. Preferences/Sources/MudPreferences.swift — the key and accessor.
3. App/AppState.swift — the published mirror, same shape as
   folderOpenBehavior.
4. App/Settings/GeneralSettingsView.swift — the picker.
5. App/DocumentWindowController.swift — the branch above,
   seedFromLastUsed, and recording from NSWindowDelegate.
6. Preferences/Tests/MudPreferencesTests.swift — round-trip and default.

Implementation summary

WindowSizeBehavior mirrors FolderOpenBehavior: String-backed,
CaseIterable, Sendable, with a label for the picker. The default is
.perFile, so an existing install behaves as it does today apart from the
better fallback.

Settings gets one Picker in the General pane's existing Section shape,
bound to $appState.windowSizeBehavior, with the same secondary-styled Text
beneath it that the folder picker uses.

In DocumentWindowController, the branch above replaces the unconditional
setContentSize + center(). windowDidEndLiveResize and windowDidMove
join the NSWindowDelegate extension, and windowWillClose gains a line,
each calling window.saveFrame(usingName: Self.lastFrameName).

windowDidEndLiveResize rather than windowDidResize: the latter fires
continuously through a drag and would write on every frame of it.

Both modes record. .perFile needs the shared slot current so a first open
has something to seed from, and so switching to .lastUsed starts at the
right size.

Verification

Clear the saved state first: defaults delete org.josephpearson.Mud, or
remove the NSWindow Frame document-window:* keys and
NSWindow Frame document-window-last.

In the default per-file mode:

1. Open a Markdown file. It appears at 860×740, centred — a fresh install,
   unchanged.
2. Fill it by dragging the title bar to the menu bar. Close it.
3. Open a different file, never opened before. It appears filled, and is
   genuinely tiled rather than just that size. (Today it appears at 860×740,
   centred. This is the change.)
4. Resize that window small. Close it.
5. Reopen the first file. It returns to filled — its own size, not the small
   one. (This is the property phase 4h set out to protect.)
6. Open a third new file. It appears small: the seed follows the last window,
   not the last file.

Then the setting:

7. Switch General → New window size to "Same as the last window you used".
8. Open the file from step 5, remembered as filled. It appears small.
9. Fill it, close it, open any other file: filled.
10. Switch back to "Remembered for each file". Open the step-5 file. It
    appears filled — the size it had before the switch, proving .lastUsed
    froze the per-file keys rather than overwriting them.
11. Confirm the setting leaves windows already on screen alone.

Both modes:

12. Capture a size on an external display, disconnect it, open a new file.
    The window is constrained to the remaining screen.
13. Confirm Quick Look and the Thumbnail extension are unaffected. Neither
    creates a document window.

Out of scope

Full screen. A document window is .resizable with the default collection
behavior, so the green button offers Full Screen and the Left/Right options
like any window. Only the View menu's "Enter Full Screen" item is hidden
(AppDelegate.menuDidAddItem, alongside the Edit menu's autofill entries).
macOS owns full-screen state, and it is not what frame autosave restores.

One interaction is worth knowing. At the macOS default for "Prefer tabs when
opening documents" ("In Full Screen Only"), a document opened while Mud is in
full screen joins the existing window as a tab and inherits its size. No
window is created, so none of this applies. That is macOS behavior, not Mud's.

Follow-up, not proposed here

The per-file keys accumulate and are never pruned. Each is
NSWindow Frame document-window:<absolute path> in
org.josephpearson.Mud.plist, roughly 200–300 bytes once the tiling blob is
attached, and nothing removes it when a file is renamed, moved, or deleted.
cfprefsd loads the file whole.

A thousand files is around 250 KB, which is small. The shape is the point: it
only grows, and nothing ever reclaims the entry for a file that no longer
exists. Phase 4h does not appear to have considered it, which is unsurprising
given per-file keying arrived as a follow-on.

.lastUsed answers this for whoever picks it — one size stored, no further
growth. It does not answer it for .perFile, and it deliberately does not
reclaim what is already there, because freezing the keys is what makes
switching back lossless.

Optional, if wanted: a "Forget remembered sizes" button beside the picker,
clearing every NSWindow Frame document-window: key at once. The smallest
thing that lets someone reclaim the space without Mud deciding on their behalf
when a remembered size has expired. Separate because both changes above stand
without it.