feat: add a rendered preview mode toggled with Ctrl+/ - #45
Open
cristim wants to merge 2 commits into
Open
Conversation
Restores a rendered view of the document alongside the in-place highlighter, reachable with Ctrl+/ (Typora's Source Code Mode key) or the eye button in the footer beside Save and Open. The preview is a separate read-only TextEdit. It never calls attachDocument, so the syntax highlighter stays bound to the source editor alone and the editing path is untouched. Rendering goes through Backend::renderPreview, which runs setMarkdown and then restores block spacing. Qt's Markdown reader packs every block flush against the next, so the blank lines that separate paragraphs in the source disappear from the render; the pass gives headings a leading gap, keeps list items tight, and puts a blank line's worth beneath ordinary paragraphs, sized from the editor font so it tracks the desktop text scale.
Three cases, driving the real code paths rather than test-only hooks: - togglesPreviewFromFooterButtonAndBack asserts the default is source, that the footer button swaps which surface is visible, and that it swaps back. - restoresBlockSpacingLostByTheMarkdownReader renders through attachDocument/renderPreview and checks headings lead their section, quotes get a leading gap, paragraphs get a trailing one, and list items stay tighter than paragraphs. Verified it fails when the spacing pass is removed. - collapsesRunsOfBlankLinesToOneGap pins the CommonMark behaviour that a run of blank lines is one separator, so the render cannot start growing with the newline count.
Author
|
Added test coverage (03ca13b) — Three cases, driving the real code paths rather than test-only hooks:
I checked the middle one is a real regression test rather than one that passes either way: with the spacing pass removed it fails with In fairness, the blank-line test passes with or without the change — it characterises Qt's behaviour rather than mine, and is there to catch a future attempt to preserve blank-line runs. The "before" screenshot above was wrong when first posted (I'd captured preview mode twice); it now shows actual source mode with the markers visible. |
frivas
pushed a commit
to frivas/omawrite
that referenced
this pull request
Aug 31, 2026
Resolved against our branch: the shortcut reference keeps rendering nativeText and gains a Preview line, and the preview renderer sits alongside the print helpers rather than replacing them.
frivas
pushed a commit
to frivas/omawrite
that referenced
this pull request
Aug 31, 2026
It had no anchors at all, so it sat at the footer's origin on top of the save icon at full opacity while everything around it was muted -- a merge artifact: PR omacom#45 placed it in a footer that PR omacom#43 had restructured, and neither conflicted textually so both landed and the button lost its position. The footer now splits the way the window does: what you can do to the file on the left, what the document is doing on the right. The icon shows the action rather than the state -- a pencil while previewing, because that click goes back to the source -- and it lifts out of the muted group while preview is on, so the mode is visible without reading anything.
frivas
added a commit
to frivas/omawrite
that referenced
this pull request
Aug 31, 2026
Resolved against our branch: the shortcut reference keeps rendering nativeText and gains a Preview line, and the preview renderer sits alongside the print helpers rather than replacing them.
frivas
added a commit
to frivas/omawrite
that referenced
this pull request
Aug 31, 2026
It had no anchors at all, so it sat at the footer's origin on top of the save icon at full opacity while everything around it was muted -- a merge artifact: PR omacom#45 placed it in a footer that PR omacom#43 had restructured, and neither conflicted textually so both landed and the button lost its position. The footer now splits the way the window does: what you can do to the file on the left, what the document is doing on the right. The icon shows the action rather than the state -- a pencil while previewing, because that click goes back to the source -- and it lifts out of the muted group while preview is on, so the mode is visible without reading anything.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Read this first: this reverses a deliberate decision
Preview mode was in the first commit and you removed it yourself in ad65d2f ("Replace preview with footer file controls", 23 Jul), along with regression tests asserting it stays gone:
Those assertions pass on this branch, but only because I named things
previewViewandpreviewButton. That is a naming accident, not a design agreement. If the intent of that commit was "no preview in this app", this PR contradicts it and you should close it — no hard feelings, and I would rather say that here than have it discovered in review.I am opening it because #3 is still open with people asking for the feature, and because the commit message gives no rationale, so I could not tell whether the removal was "not like this" or "not ever". If it was the former, this is a concrete proposal. If the latter, say the word and I will close it and add the guard for the new names myself.
What it does
Ctrl+/(Typora's Source Code Mode key) or the eye button in the footer, beside Save and Open, swaps the source buffer for a rendered view. The original usedCtrl+E; I went withCtrl+/for Typora parity, butCtrl+Eis a one-line change if you prefer the old binding.How
The preview is a separate read-only
TextEdit. It never callsattachDocument, soMarkdownHighlighterstays bound to the source editor alone and the editing path is untouched.Rendering goes through
Backend::renderPreview, which runssetMarkdownand then restores block spacing. Qt's Markdown reader packs every block flush against the next, so the blank lines that separate paragraphs in the source vanish from the render. The pass gives headings a leading gap, keeps list items tight, separates blockquotes (viaQTextFormat::BlockQuoteLevel), and puts a blank line's worth beneath ordinary paragraphs — sized from the editor font so it tracks the desktop text scale.Multiple consecutive blank lines collapse to one gap. That is deliberate: CommonMark treats them as equivalent, and the
Ctrl+Ppath already renders them that way.Verification
bin/test— 12 passed, 0 failed, including the two assertions above.Known gaps
previewMode = falseon Find/Replace. I did not restore either; both are worth adding if this direction is acceptable at all.