fix(web): remember the rendered-markdown choice across threads

[Sy-D]

What Changed

The rendered-markdown choice in the file preview panel is now a persisted preference instead of panel state tied to one file path.

Why

Reported in #4645. The state was:

const [markdownView, setMarkdownView] = useState<{ path: string | null; revealRequestId: number | null }>(...)
const renderMarkdown = isMarkdown && markdownView.path === relativePath && ...

It said "rendered is on for this file", so leaving the thread tore the panel down and returning showed source again. The reporter describes it as a preference — "once I've said I want to read markdown rendered, that's my preference until I toggle it back" — so it now persists the way this same panel already persists its explorer state (FILE_EXPLORER_STORAGE_KEY / initialExplorerOpen), rather than introducing a new mechanism or touching the settings schema.

A line reveal still wins over the preference, because a line only exists in the source. It no longer clears the preference on the way past, so toggling once returns you to rendered.

Notes For Review

A limitation worth knowing, which this PR does not change. rightPanelStore keeps revealLine / revealRequestId as durable surface state and rehydrates them. So if the last thing you did with a file surface was jump to a line, returning to it still shows source: the stored reveal is indistinguishable, at mount, from a fresh one, and treating it as already handled would break the case the reveal exists for — clicking a line link while the panel is closed.

That is not a regression. Before this change, returning showed source in every case; now it shows source only in that one. Making it complete means letting the store consume a reveal once it has been applied, which changes shared surface semantics and its persistence, so it felt like a separate change rather than something to fold in here.

Validation

Driven in a running client, on a markdown file whose own content links back to itself so the reveal path can be exercised:

step	expected	observed
Toggle rendered	preference stored	t3code.renderMarkdown = true, view rendered
Click a README.md:9 link while rendered	source, line revealed	toggle flipped to source; preference still true
Toggle back	rendered	rendered
Leave the thread and return, no pending reveal	rendered	rendered — verified by the reporter

The last row is the reported scenario. I could not reproduce it myself: the file explorer in my seeded fixture workspace lists no files, so I had no way to open a markdown file without going through a line link. It was checked by the reporter on a real project instead, and I am flagging that rather than implying I measured it.

• vp run --filter @t3tools/web test — 1663 passed
• vp run --filter @t3tools/web typecheck — no errors
• vp lint / vp fmt --check on the changed file — clean

Closes #4645.

Checklist

• This PR is small and focused
• I explained what changed and why
• No visual change beyond which of the two existing views is shown

---

Note

Low Risk
UI preference persistence in the file preview panel only; no auth, data, or API changes.

Overview
Fixes #4645 by persisting the file preview rendered markdown toggle in localStorage (t3code.renderMarkdown) via useLocalStorage, matching how explorer open/close is already stored—not per-file panel state that reset when switching threads.

Line reveals still force source view (the line only exists there). A new handledReveal state pairs path with revealRequestId so a reveal handled on one file does not block reveals on another; toggling rendered again records the current reveal as handled without clearing the stored preference.

^{Reviewed by Cursor Bugbot for commit 3238bcb. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Persist rendered-markdown toggle choice across threads in FilePreviewPanel

• Replaces the local markdownView state with a useLocalStorage-backed preference keyed at t3code.renderMarkdown, so the toggle choice survives navigation between threads and files.
• When a line reveal is active for a file and hasn't been marked as handled for that path/requestId, the panel forces source view regardless of the stored preference.
• Toggling to rendered markdown records the current file path and requestId as handled, preventing the reveal logic from overriding the preference again for the same request.

^{Macroscope summarized 3238bcb.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 69531c48-b272-4ff3-be92-50f2be9e8509

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit dae51be. Configure here.}

[macroscopeapp]

Approvability

Verdict: Approved 3238bcb

This PR makes a simple change to persist the markdown rendering preference to localStorage using an existing hook. The change is self-contained with no security or schema implications, and the open review comment is just a clarifying question (the hook already exists).

^{You can customize Macroscope's approvability policy. Learn more.}

[Sy-D]

Right on both counts, and it was a regression I introduced — the state I replaced paired the path with the request id, and I dropped the path. Fixed in a533f3a.

Confirmed the precondition rather than taking it on faith. rightPanelStore derives the id per surface:

const surfaceId = `file:${relativePath}`;
const surface = fileSurface(relativePath, normalizeRevealLine(line), (existing?.revealRequestId ?? 0) + 1);

so every file starts counting at one. Reproduced with two markdown files that link to each other by line, and read the persisted store afterwards:

README.md: revealLine=9 requestId=1
NOTES.md:  revealLine=5 requestId=1

Both at 1, exactly the collision described. Walked through it in a running client:

step	expected	observed
Click README.md:9	source, line revealed	source
Toggle back to rendered	rendered, reveal dismissed	rendered
Click NOTES.md:5 from there	source — different file, its own first reveal	source

Without the pairing the last row would have stayed rendered, since the stored id 1 matched.

handledReveal now carries { path, requestId } and the comparison checks both.

vp run --filter @t3tools/web test — 1663 passed. Typecheck and lint clean.

[juliusmarminge]

do we not have a useLocalStorage hook yet??

[Sy-D]

We do see comment below @juliusmarminge fixed it and why this approach has been chosen previously.

[Sy-D]

oh yea we do and its used by editorPreferences, providerUpdateDismissal and a couple of others. Switched to it in 3238bcb.

I had followed the neighbouring pattern in this file instead: FILE_EXPLORER_STORAGE_KEY with initialExplorerOpen() and a manual setLocalStorageItem in the toggle, a few lines above where this landed. Matching the file seemed safer than reaching past it, but the hook is more sleek than using multiple try catch..

PS: the explorer state right above still uses the hand-rolled version. Happy to convert it too, but it is unrelated to this fix so I left it alone rather than widening the diff.

Dismissing prior approval to re-evaluate 3238bcb