fix issue up/down first/last line not jumping to begin/end

[louwers]

Take into account Qt::KeypadModifier in the if-statement.

[Copilot]

Pull request overview

Updates key handling in QMarkdownTextEdit::eventFilter so that pressing Up/Down at the start/end of the document works correctly even when the arrow key originates from the numeric keypad (i.e., with Qt::KeypadModifier).

Changes:

• Add special-case handling for Qt::Key_Up / Qt::Key_Down at the first/last line.
• Treat Qt::KeypadModifier as equivalent to “no modifier” for this behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The modifier check modifiers().testFlag(Qt::KeypadModifier) will also match combinations like Ctrl+Shift+Keypad, so this branch can intercept shortcuts handled later in this chain (e.g. Ctrl+Shift+Down/Up for moveTextUpDown) when the arrow key comes from the numeric keypad. To avoid breaking those key combos, restrict this condition to only no modifiers or keypad-only (e.g. compare modifiers() for equality, or mask out KeypadModifier and ensure no other flags are set).

[pbek]

@louwers, please review

[Copilot]

Same issue here: testFlag(Qt::KeypadModifier) will be true even when other modifiers are pressed (e.g. Shift/Ctrl with keypad arrows), which can change or bypass intended behavior for those combos. Limit this branch to the keypad-only/no-modifier cases (e.g. modifiers() == Qt::NoModifier || modifiers() == Qt::KeypadModifier).

[pbek]

@louwers, please review

[pbek]

And is

qmarkdowntextedit/qmarkdowntextedit.cpp

Lines 2415 to 2419 in c84c08e

	// Handle boundary arrow navigation here because Qt6 no longer reliably
	// runs the event-filter path for these cursor moves on macOS.
	if (handleBoundaryArrowNavigation(this, event)) {
	return;
	}

(including the method implementation) then redundant and can be removed?

[louwers]

@pbek Oh yes it is.

[louwers]

Let me close this and open a new PR, somehow I only expected this to be a two line change.