Address issue #382: Normalize CRLF line endings on file load#398
Merged
Conversation
Windows-created files use CRLF (\r\n) line endings. Hoedown's line-based parser expects LF (\n) and fails to render headings, paragraphs, and other block elements when encountering \r\n, producing blank output for Windows files while Mac files render correctly. Fix applied at three levels of defense: - readFromData:ofType:error: (MPDocument.m): strips \r\n at load time so the editor and all downstream code see LF-only content; saving a Windows file will write back LF (standard Mac editor behavior) - renderMarkdownFromURL:error: (MPQuickLookRenderer.m): same normalization for the Quick Look path, which loads files independently - MPPreprocessMarkdown (MPRenderer.m): safety-net strip before Hoedown for content arriving via paste or programmatic assignment Tests added for basic CRLF rendering, list-after-paragraph (Issue #254) and fenced-code-after-text (Issue #36) workarounds with CRLF, Quick Look CRLF rendering, and document load API coverage. Related to #382
Contributor
Code Coverage ReportCurrent Coverage: 60.48% Coverage Details (Summary) |
This was referenced Jun 22, 2026
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
2 participants
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.
Summary
\r\n) line endings. Hoedown's line-based parser expects LF (\n) and fails to render block elements (headings, paragraphs, lists, code blocks) when it encounters\r\n, producing a blank preview.MPDocument.m), in the Quick Look renderer (MPQuickLookRenderer.m), and as a safety net inMPPreprocessMarkdown(MPRenderer.m) for content arriving via paste or programmatic assignment.MPPreprocessMarkdownregexes that fix Issues Rendering of lists is off if it doesn't have a blank line before it #254 and Fix code block formatting when no blank line before block #36 also match\nonly, so normalizing before those patterns is required for CRLF files to benefit from those workarounds.Related Issue
Related to #382
Manual Testing Plan
Since a Windows machine is not available, create CRLF test files on macOS using Python:
Scenarios:
basic.mdopens in MacDown and shows rendered<h1>and<p>(not a blank preview)list.mdshows paragraph and<ul>as separate blocks (Issue Rendering of lists is off if it doesn't have a blank line before it #254 workaround still works)code.mdshows a rendered code block (Issue Fix code block formatting when no blank line before block #36 workaround still works)Review Notes
reloadFromDiskrequires no change — it calls through toreadFromData:ofType:error:and inherits the fix automatically.NSString+Lookup.mfront matter CRLF handling is left unchanged; the defensive[\r\n]+patterns are harmless and provide a useful backstop.\r(legacy Mac OS 9 line endings, obsolete since 2001) is not handled; the risk was judged negligible.