fix: report the document's real line ending in the status bar

[PathGao]

The editor's status bar ends with two hardcoded strings:

<div class="status-item">{t('editor.status.crlf')}</div>
<div class="status-item">{t('editor.status.utf8')}</div>

Neither is measured. The app tells every user their file is CRLF and UTF-8, whatever it actually is — samples/stress-test.md contains zero CR bytes and the status bar said CRLF.

Found while fixing #148, which was a bug about line endings the whole way down: the write-back mis-resolved a line because a pattern ate a \r, three fixes missed it because they were verified on macOS, and the suite's own convention (readSource instead of readFileSync) exists because a CRLF checkout on Windows once turned fifteen test files red. Through all of that, the one place in the app that claims to report a document's line ending was reporting a constant.

The line ending

model.getEOL(), surfaced through lineEndingLabel and rendered next to the language and word count in syncStatusFromModel — the existing home for document-wide readings, already re-run on tab switch and on content change.

Not a fourth detector. Monaco's buffer builder already decides this: createTextBufferFactory counts CR/LF/CRLF and, with normalizeEOL at its default, rewrites the whole buffer to the majority ending before the model exists. So getEOL() is not an opinion sitting beside the bytes — it is the bytes, and it is what a save writes out.

detectLineEnding in frontMatter.ts stays where it is. It answers a different question — which ending to emit when rewriting a front-matter block in a string it was handed — and lifting it into a shared helper would have meant more code for a less accurate answer.

Mixed endings need no third label, because by the time anything can be displayed the document is no longer mixed. a\r\nb\r\nc\n normalizes to CRLF and reports CRLF; a tie goes to LF, since Monaco requires a CR majority rather than a plurality. The test asserts the normalized buffer contents alongside the label, so it pins the claim and not just the string.

A document with no line break at all — an empty untitled tab, a one-line file — has nothing to detect and falls back to the model's defaultEOL, which the standalone services resolve per platform. So the same empty tab honestly reads CRLF on Windows and LF on a Mac, which is what Enter will insert and what the save will write. Covered by a test.

The encoding indicator is deliberately untouched

fix/non-utf8-documents (#372) implements real detection — BOM sniff, then chardetng — and carries the answer on Tab.encoding so a legacy document can be written back in its own encoding. That branch declares the field as required, deliberately, so a construction site cannot forget it and silently rewrite a GBK file as UTF-8.

Wiring the label to it here would mean declaring the field on Tab in this PR too: a duplicate, always-'UTF-8' answer to a question that branch answers properly, four more construction sites to keep in sync, and a guaranteed conflict in the interface when it lands. The guard would never fire, so the label would read UTF-8 exactly as it does now — the same lie with more code behind it.

The markup carries a comment naming the branch, the issue and the field. Wiring it once #372 lands is a one-line follow-up.

i18n: five keys removed, none added

LF and CRLF are acronyms. The existing crlf key held the identical ASCII 'CRLF' in the five locales that defined it, and the other 21 fell through to English — it was carrying zero information. The neighbouring status items ({zoomLevel}%, {currentLanguage}) render raw, so raw is the local convention. editor.status.utf8 stays until the encoding branch lands.

Validation

• npm test 850 · npm run check 667 files, 0 errors · cargo test 141 (Rust untouched)
• scripts/editorLineEnding.test.ts builds real Monaco piece-tree buffers the way createModel does and pushes them through the real lineEndingLabel: CRLF → CRLF, LF → LF, three mixed fixtures with their normalized contents asserted, plus the no-line-break case.
• Verified it fails against the old code — restoring the hardcoded string turns the wiring test red.

Two existing harnesses (undoHistoryPerTab, imageUndoKeepsFile) lift syncStatusFromModel out of the component and eval it; they now receive the real lineEndingLabel and a fixed getEOL on their fake models. Fixed that way on purpose — a fake that guessed an EOL from its own buffer would be a second implementation of the thing this removes.

Not verified: no run of the packaged app, so "the status bar visibly reads LF on stress-test.md" is inference from the wiring plus the Monaco behaviour exercised directly. The Windows-default case is read out of standaloneServices.js and driven through an explicit defaultEOL, not on a Windows machine.

🤖 Generated with Claude Code