fix: scroll to document start/end on Ctrl+Home/End in Rendered view

[moabtools]

Description

In Rendered view, each markdown block (paragraph, heading, list item, etc.) is rendered as an inline TextEdit. When focus is inside one of those widgets, Ctrl+Home and Ctrl+End are consumed by the inner TextEdit and move the cursor to the start/end of that single block — not to the start/end of the document, as users expect.

This PR intercepts those keys at the ScrollArea level — before the inner TextEdits see them — and applies the appropriate vertical_scroll_offset.

Raw view was already correct (handled in src/editor/ferrite/input/keyboard.rs), so this only touches the Rendered/Split path.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement

Changes Made

• Detect Ctrl+Home / Ctrl+End in MarkdownEditor::show_rendered_editor (in src/markdown/editor.rs) before the ScrollArea is built.
• For Ctrl+Home: set vertical_scroll_offset(0.0).
• For Ctrl+End: read the cached total_height from the prior frame's ViewportCullingState (falls back to a large finite value on the first frame). f32::INFINITY was tried first but broke egui's scrollbar arithmetic — content area collapsed and the scrollbar disappeared — so a finite value (clamped by egui) is used instead.
• Remove the matching Key::Home / Key::End events from the input queue so the focused TextEdit doesn't also navigate within its block.
• Place this as the highest-priority source in the existing scroll-offset chain (above nav-button scroll, mode-switch pending scroll, and outline-navigation scroll).

Checklist

• My code follows the project's code style
• I have run cargo fmt and it produces no changes to the lines this PR touches (pre-existing trailing-whitespace findings elsewhere in the tree are not addressed here to keep the diff focused).
• I have run cargo clippy — no new warnings from this change (the existing 471 pre-existing warnings in the tree are unchanged).
• I have run cargo test and all tests pass (1477 passed, 0 failed, 2 ignored).
• I have run cargo build --release successfully.
• I have updated documentation if needed (no docs changes needed — this is a UX fix to match standard editor behavior).
• I have added tests for new functionality (no automated tests added — the behavior is a ScrollArea interaction that's hard to assert without a UI harness; verified manually as described below).
• My changes generate no new warnings

Testing

Verified manually on Windows 10 with a cargo build --release build:

1. Open a long markdown file (multiple screens of content).
2. Switch to Rendered view.
3. Scroll to the middle of the document.
4. Press Ctrl+Home → view scrolls to the very top. ✓
5. Press Ctrl+End → view scrolls to the very bottom; scrollbar remains correct. ✓
6. Repeat in Split view (right pane uses the same EditorMode::Rendered path) → works. ✓
7. Raw view unchanged (it was already correct via src/editor/ferrite/input/keyboard.rs). ✓
8. With focus inside an inline editable block in Rendered view: the keys still navigate the document instead of the block. ✓

Additional Notes

• One small edge: if Ctrl+End is pressed on the very first frame after opening a file (before ViewportCullingState has measured any blocks), the scroll uses the 1.0e9 fallback. egui clamps this to the actual max scroll position, but if the culling state hasn't measured everything yet, the bottom may be approximate; a second press lands precisely. In practice this is hard to hit — by the time a user can press a shortcut, at least one render frame has measured the culling state. Happy to add a request_repaint + second-frame application if reviewers prefer a stricter guarantee.
• I considered promoting this to an app-level ShortcutCommand so it would be user-configurable from the settings UI, but that adds more surface area for what is essentially a fix to match expected behavior. Open to that direction if the maintainer prefers.

Summary by CodeRabbit

• Bug Fixes
  • Fixed Ctrl+Home and Ctrl+End keyboard shortcuts in rendered editor mode to properly jump to the document start and end.
  • Improved keyboard event handling to prevent navigation shortcuts from being intercepted by text editing widgets.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: da0cf751-f44a-44a1-bcc8-a3c723666ea1

📥 Commits

Reviewing files that changed from the base of the PR and between acdd980 and 2b35900.

📒 Files selected for processing (1)

• src/markdown/editor.rs

---

📝 Walkthrough

Walkthrough

The editor in rendered mode now supports document navigation shortcuts: Ctrl+Home jumps to the document start and Ctrl+End jumps to the document end. The implementation detects these key presses, computes appropriate scroll offsets (using cached viewport dimensions for accurate end-of-document positioning), and prevents the key events from being consumed by inline editors so navigation is not trapped within focused text blocks.

Changes

Document Edge Navigation

Layer / File(s)

Summary

Ctrl+Home/End detection and scroll offset computation src/markdown/editor.rs

In rendered mode, Ctrl+Home and Ctrl+End key presses are detected and trigger document-edge jumps. A doc_edge_scroll offset is computed (using cached ViewportCullingState.total_height for accurate end-of-document positioning) and filtered from input events to prevent inline TextEdit widgets from consuming these keys. The scroll system prioritizes document-edge jumps above nav-button, mode-switch, and outline navigation scrolls.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

A rabbit scrolls to journey's start,
With Ctrl+Home as the quick-nav art,
To document's end, a swift key press—
No TextEdit traps, just smooth progress! 🐰⌨️

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly describes the main change: adding Ctrl+Home/End scroll navigation to document edges in Rendered view, matching the core fix implemented in the changeset.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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 and usage tips.}

[OlaProeis]

@moabtools

Thanks for this PR!
*
Looks very clean, i will include this in the upcoming 0.3.0 release.

Currently working on Egui upgrade, its going well, so 0.3.0 will be expected this weekend.