Fix inverted RTL word navigation in the subtitle edit box

[muaz978]

What

Fixes Ctrl+Left / Ctrl+Right jumping the wrong way when editing a right-to-left subtitle (e.g. Arabic), and makes Ctrl+Up / Ctrl+Down go to the start / end of the current line.

Why

Avalonia's TextBox moves the caret one character visually (bidi-aware, already correct) but moves whole words by logical text offset, so word steps run opposite to the visual direction under RTL. Single-character steps were fine; word steps were inverted.

How

A tunnel-phase key handler on the main and original edit text boxes that runs only when the box is in RTL flow:

• Ctrl+Left / Ctrl+Right move a word in the visually-correct direction.
• Ctrl+Up / Ctrl+Down move to start / end of the current line.
• Shift extends the selection.

It no-ops for left-to-right editing, so LTR behaviour and global Ctrl+Arrow shortcuts are unchanged.

Note: please verify in a real RTL editing session - developed on macOS, not yet runtime-tested.

[GrampaWildWilly]

This caught my eye because there was a recent fix made to let Ctrl+Right/LeftArrow skip words instead of navigating the video. This was an issue of there being shortcuts for video navigation that happen to collide with Windows standard keyboard combinations that navigate text. The solution was to suspend recognition of the shortcuts while focus is in the text box. At least, that's my understanding of the solution. I'm just a user. I have no hope of ever actually understanding the code were I to see it.

However, I take issue with your selection of Ctrl+Up/DownArrow as text movement keyboard directives. These are NOT standard text editing operations in Windows. To go to the beginning of a line, the standard keyboard operation is the Home key. For line end, it's the End key. To go to the beginning of the text in the textbox -- like if there's 2 lines of text & the cursor is somewhere in the second line -- the standard key combination is Ctrl+Home. To go to the end of the text, it's Ctrl+End. So I say that you should remove whatever logic you have coded to recognize Ctrl+Up/DownArrow. The keystrokes I have described are provided by Windows itself & these should simply be allowed to operate within the textbox. This should not be an issue of left-to-right vs right-to-left text orientation. To my way of thinking, making sure Ctrl+Left/RightArrow swap directions depending on RTL or LTR seems valid. But the rest does not seem valid. In addition, I would assume there are keyboard operations on Mac that are equivalent to the ones I've described for Windows. You should not add code that duplicates what the operating system already provides. If standard keystrokes don't filter through in the textbox on Mac, you should be looking at suspending colliding shortcuts from interfering with standard text operations defined in the operating system, not customizing new keystrokes to circumvent the root cause.

[muaz978]

Thank you for your comment,

In SE4, on Windows, ctrl + up or down arrows would take you to the head or end of the line you are in if your are using the text box, double do that and it would take you to the head of the first line if you were in the second in case you had two. However, this was not functioning properly in latest 5 release, and in Arabic language it is even inverted, that is what I was trying to fix actually.

[muaz978]

Still working on this, and will confirm once I test it myself.

[muaz978]

Tested and working on macOS 26.5 (Apple Silicon) from a local build of this branch, with Arabic subtitles, in both edit-box modes (the AvaloniaEdit editor used when color tags are on, and the plain TextBox).

Behaviour (right-to-left text only)

For a focused subtitle edit box whose content is right-to-left, caret navigation now moves in the visually-correct direction, using each platform's standard navigation keys:

• Word — Ctrl+Left/Right (all platforms); Option(Alt)+Left/Right (macOS). Moves one word in the visual direction of the arrow.
• Line — Cmd(Meta)+Left/Right (macOS). Moves to the visual start/end of the current line.
• Shift + any of the above extends the selection, and repeated presses grow it word-by-word / out to the line edge.
• Bare Left/Right with an active selection collapses it to the visually-correct edge (Left → left edge, Right → right edge). With no selection, single-character movement is left to the editor (it was already bidi-correct).

Why it lives in the key pipeline

A handler attached directly to the TextBox / AvaloniaEdit TextArea does not reliably win against AvaloniaEdit's built-in caret commands. So this is handled in the central OnKeyDownHandler, in the root tunnel phase — the same place the edit box already overrides keys (e.g. the Return-key line limiter) — where marking the event handled cleanly pre-empts the editor's inverted logical-order navigation. Movement goes through the ITextBoxWrapper abstraction, so it works for both edit-box implementations.

Two implementation notes:

• RTL is detected by content, per line with a whole-box fallback — a subtitle is normally edited in an otherwise left-to-right window, so the control's FlowDirection stays LtR even for Arabic; keying off FlowDirection doesn't work.
• AvaloniaEdit relocates the caret of a programmatic selection back to its anchor between key presses, which broke growing a selection. The selection's fixed anchor and moving end are now tracked in the view model, so Shift+word/line accumulates correctly.

Scope — what is NOT affected

• Left-to-right text: the handler returns immediately — native navigation everywhere, unchanged.
• Non-arrow shortcuts (copy/paste/undo), Home/End, Ctrl+Home/Ctrl+End: untouched.
• Windows: the only change for Windows users is Ctrl+Left/Right word-jump inside RTL text (the same inversion fix); English/LTR editing is unchanged. The Option/Cmd handling is macOS-only.

Verified on-device: word nav (Option and the Cmd-position key), line nav, Shift-extend accumulation across multiple words and to line edges, bare-arrow collapse to the correct edge, and LTR/English left unaffected.

[muaz978]

Is there any changes or enhancements that you suggest me to edit or improve?
The last version I comitted was clean and tested it myself, I got a notification that it now has conflict, but didn't understand what was really changed, can you advice on this please?