Let the user set their own text size

[r3quie]

I was missing a feature to change text size on the fly.

Summary:

• Adds bindingsCtrl+=, Ctrl+-, Ctrl+0, and Ctrl+wheel to control text size
• Uses Chromium's zoom ladder, 67% to 200%
• The footer reports each change
• The size persists to the next window

Tested: bin/test passes (14, two of them new), and stepping the built app from 75%
to 150% scales the editor text, footer, and column width together.

[Liam-Griffiths]

I'd also like this feature.

[omarchybot]

Reviewed this and drove the real Main.qml rather than reading behaviour off the diff. One fix pushed to your branch, two things still open.

Pushed (ee6e551): Ctrl++ and numpad + did not zoom in. "Ctrl+=" registers Qt::Key_Equal, and pressing Shift and = resolves through QXkbCommon::possibleKeys to Ctrl+Plus — a different combination, which Ctrl+= does not match. On a layout that puts + on its own key (German, Czech, the Nordic ones) nothing produces Ctrl+= at all, so those users had no way to make the text bigger at all. sequences: ["Ctrl+=", "Ctrl++"] covers both, and the numpad keys fall out of it because Qt strips KeypadModifier before matching shortcuts. There is a test that fails without the change. Ctrl+- needed nothing — minus is unshifted on those layouts.

Open: a text size change scrolls the view back to the caret. onCursorRectangleChanged: editorFlick.ensureCursorVisible() (Main.qml:612) fires when the font size changes the cursor rectangle, not only when the caret moves. With a 400-line document, the caret left at the top and the view parked at contentY 5000, one Ctrl+= leaves contentY at 0 — and so does one Ctrl+wheel notch. Zooming in only grows contentHeight, so nothing is clamping this; it is the jump to the caret. Reading in the middle of a long file and nudging the size throws you back to the top, on every step. Left for you because what zoom should do to the reading position is a call about the app, not a bug with one obvious fix.

Open, minor: the ladder drops Chromium's 80% rung. Chromium's is 0.25, 1/3, 0.5, 2/3, 0.75, 0.8, 0.9, 1.0, 1.1, ..., so 90% → 75% here is a coarser step than "Chromium's zoom ladder, trimmed to the range the whole window still reads well at" promises — trimming the range takes the ends off, not a rung out of the middle.

The rest held up under test. The 67%–200% clamp is enforced in the backend, so Ctrl+wheel past an end banks nothing and does not lurch when you reverse. A corrupt, empty, negative, zero, NaN or non-numeric text/zoom falls back to 100%, and an absurd one clamps to 200%. The while loops are bounded and cheap: a 100,000px pixelDelta, orders of magnitude past anything a compositor sends, ran in 8ms and settled at 200% with the bank drained to zero. Your own size composes with the desktop textScale rather than replacing it, at startup and on a live desktop change. bin/test is green at 15.