Title: Cursor movement (arrow keys) is broken/inconsistent in mixed RTL-LTR (Arabic/English) text — reproducible in Sandbox Vault
Environment:
- OS: Ubuntu 26.04.1 LTS x86_64
- Obsidian: [insert your exact version from Settings > About]
- Tested in: Sandbox Vault (default vault, zero community plugins enabled) — this isolates the bug to Obsidian’s core editor rather than any plugin.
Steps to reproduce:
- Open a fresh Sandbox Vault.
- Create a new note and type a paragraph mixing Arabic (RTL) and English (LTR) text/words within the same line(s).
- Try navigating through the text using the plain arrow keys (Left/Right), and also test Home/End.
- Observe cursor behavior when crossing between an RTL segment and an LTR segment, and when moving between lines/paragraphs of different base direction.
Observed behavior:
- Arrow key direction flips inconsistently depending on the underlying language of the text run at the cursor position, rather than following a single predictable rule.
- This produces situations where repeatedly pressing the same arrow key moves the cursor back and forth between the same two positions instead of progressing through the text (effectively a navigation loop at RTL/LTR boundaries).
- Home/End keys are similarly affected and do not reliably jump to the visual or logical start/end of the line.
- Ctrl+Arrow (word-jump) exhibits the same inconsistency, not just plain arrow presses.
Why this matters / root cause hypothesis:
Obsidian’s editor (CodeMirror 6) implements its own cursor-position logic in JavaScript rather than delegating to the browser’s native BiDi engine (this is confirmed by testing side-by-side in another Electron/Chromium app, Brave, where the native browser BiDi cursor behavior works correctly — ruling out Electron/Chromium/OS-level causes and pointing specifically to CM6’s own implementation inside Obsidian).
This appears to be the same underlying issue acknowledged by the maintainer of the community RTL plugin (esm7/obsidian-rtl) in that plugin’s own changelog: “Mixed LTR-RTL tables are supported, but due to Obsidian’s current cursor movement implementation, moving between cells with different directions using the keyboard arrows isn’t great.” This confirms the limitation is in Obsidian core, not something a plugin can fully work around.
Proposed solutions (either would be a major improvement over the current inconsistent “visual” default):
-
Fixed global arrow convention: Right arrow always advances the cursor and Left arrow always retreats it, consistently, regardless of the direction of the text run under the cursor. This removes ambiguity entirely and eliminates the navigation-loop behavior, at the cost of the arrow not always matching the visual on-screen direction of a given RTL segment.
-
Per-paragraph direction convention: The direction convention (which arrow = advance vs. retreat) is determined once by the paragraph’s first word/character (RTL or LTR), and stays fixed for the entire paragraph — rather than switching per individual word/run as it currently seems to. This preserves a more “natural” feel for users reading primarily in one direction with embedded foreign words, while still avoiding the same-paragraph flip-flopping loop. (Note: this may still require a clear, documented convention for what happens exactly at paragraph-to-paragraph boundaries with different base directions.)
Either approach would remove the current default of switching direction mid-paragraph based on the immediate text run, which is the root cause of the disorientation and navigation loops described above.
Happy to provide a sample note/screen recording if useful for reproduction.