RTL Writing Tools: Why Text Direction Matters More Than You Think

Open Google Docs. Type some Arabic. Then type an English word in the middle of the sentence. Watch where the cursor lands. Try to select across the script boundary. Try to put a period at the end of the Arabic phrase.

Now ask yourself why this, in 2026, in a product made by Google, used by hundreds of millions of people, still feels like wrestling.

I've spent more time than I'd like to admit reading the Unicode Bidirectional Algorithm spec and W3C's International Text Layout guidance because my product is an RTL writing tool and I have to get this stuff right. After two years of it, I have strong opinions about why most editors fail at right-to-left, what a real Arabic-first editor looks like, and which signals separate the two when you're shopping for one.

The hidden tax of bad RTL

Most articles about RTL talk about it in cosmetic terms: the text looks wrong, the buttons are on the wrong side. That misses the point. The real cost of bad RTL is cognitive interruption.

Every time the cursor lands somewhere unexpected, your brain context-switches from "what am I writing?" to "how do I make this tool work?" In a focused writing session, you context-switch a few hundred times. Multiply across a year of writing and you've spent dozens of hours not on your work but on your tool.

This is why so many Arabic writers describe their workflow as "fighting" their software. They're not exaggerating. They're describing a real friction tax, one that LTR-language writers don't pay.

The five specific things editors get wrong

Through testing every Arabic-supporting writing tool I could get my hands on, Google Docs, Microsoft Word, Notion, Obsidian, iA Writer, Bear, Craft, Logseq, Lexical-based products, ProseMirror-based products, I've found the same handful of bugs in almost all of them.

1. Cursor jumps in mixed text

You type an Arabic phrase, then an English word, then keep typing Arabic. The cursor lands in the wrong logical position because the editor isn't sure which directional context "owns" the cursor at the boundary. The visual location and the actual insertion point disagree.

What a proper editor does: uses logical (memory) order for cursor positioning, not visual order. The cursor follows what you wrote, not what you see.

2. Punctuation drift

You type a period at the end of an Arabic sentence. It renders before the Arabic, to the right, where the sentence "ends" logically, but visually it ends up clinging to a Latin word that came earlier. Or you type a question mark and it shows up in the wrong shape (Arabic ؟ vs Latin ?) because the editor doesn't know which script context applies.

What a proper editor does: uses the Unicode BiDi algorithm correctly, including proper handling of "neutral" characters (punctuation, spaces) which inherit direction from their surroundings. Bonus points: auto-substitute Arabic punctuation when in Arabic context (٪ instead of %, ، instead of ,, ؟ instead of ?).

3. Selection bugs across direction boundaries

You drag-select from an Arabic word to an English word. The editor either selects too much, too little, or chunks in a non-intuitive way. Cut/copy/paste preserves bad selection state.

What a proper editor does: treats selections as logical-order ranges, not visual rectangles. The selection follows the text in memory.

4. Mixed-list disasters

You have a numbered list in Arabic. You insert an English-named item in the middle. The numbers count in the wrong direction. The bullet alignment breaks. Nesting indents go the wrong way.

What a proper editor does: uses dir="rtl" at the appropriate scope so list markers, indents, and counters all flip correctly. (This is a place where even good editors regress, RTL lists are a known weakness in Notion, Obsidian, and Logseq as of mid-2026.)

5. Toolbar logic is LTR-brained

Every toolbar button assumes "left = beginning, right = end." Indent right means "indent in", but in RTL that's the wrong direction. Many editors get the buttons right but get the keyboard shortcuts (Cmd+] vs Cmd+[) wrong.

What a proper editor does: flips the meaning of directional shortcuts in RTL context, not just the visual position of toolbar buttons.

What "Arabic-first" actually means

The phrase gets thrown around in marketing. Here's what it has to mean to be a real claim:

Default direction is RTL, not "supported." When you open a fresh document, the language and direction are Arabic. You don't "switch" to Arabic mode. The English version of the editor is the alternate mode, not the canonical one.

The Unicode BiDi algorithm is implemented end-to-end, cursor positioning, selection, find-and-replace, undo/redo all respect logical-order positions, not visual positions.

Mixed-content handling works at all levels, sentences, paragraphs, lists, tables, headings, footnotes. Not just the body text.

Typography is tuned for Arabic, Arabic script needs more line height than Latin (the strokes hang lower; tashkeel needs vertical room), often less font weight (Arabic is naturally heavier), and different spacing rules. A one-size-fits-all approach makes Arabic look cramped and hard to read.

Fonts are real Arabic fonts, not Latin fonts with Arabic fallback. IBM Plex Sans Arabic, Noto Naskh Arabic, Scheherazade New, Amiri, these were designed specifically for Arabic screen readability. Most editors default to fonts optimized for Latin.

Tashkeel renders correctly, diacritics (fatha, damma, kasra, shadda, sukun) need to overlap their base letter without breaking line height, and need to be visible at body-text sizes. Many editors render them as overlapping smudges or invisible specks.

Features beyond direction that matter to Arabic writers

RTL handling is the floor. Above that, four features matter for actually getting work done:

Quranic citation

If you're writing about Islam, the most common citation in your work is a Quranic verse. Looking up the verse, copying it, formatting it correctly with the ayah number and surah name, and doing this 50 times in a thesis, is a real time sink.

What you want: a /quran command (or equivalent) that searches by topic or text, inserts the verified Arabic text with mushaf-style numbering, and links back to the source. Nuss does this; no other general-purpose editor does.

Mixed-script typography

You're writing in Arabic and need to embed an English author name, a URL, or a code identifier. The two scripts have different baselines, different font-size requirements, and different surrounding-space conventions. A good editor handles the transition smoothly.

Footnote and citation support

Arabic academic writing relies heavily on footnotes. The numbering needs to count in Arabic-Indic numerals (١، ٢، ٣) by default. Footnote markers need to align correctly in RTL flow.

Export that doesn't break

PDF, Word, Markdown, when you export an Arabic document, the direction needs to survive. Many editors export Arabic that displays correctly on screen but renders left-to-right in PDFs. Test this before committing.

The 8 questions to ask when choosing an Arabic-friendly editor

When evaluating any editor for serious Arabic writing, here's the checklist. Run them yourself; don't trust marketing pages.

1. Open a fresh document. Does it default to RTL, or do I have to switch?
2. Type "I love اللغة العربية very much." Where does the cursor land after each script switch? Does selection work intuitively?
3. Type an Arabic sentence ending with a period. Does the period stay where I put it, visually and logically?
4. Make a numbered list with Arabic items. Add an English-named item mid-list. Do the numbers stay in order? Are they Arabic-Indic numerals?
5. Embed a URL in an Arabic paragraph. Does the URL render LTR within the RTL flow without breaking the surrounding text?
6. Type a word with full tashkeel: "كَتَبَ". Are the marks visible and properly positioned?
7. Export the document to PDF. Does the Arabic survive direction, font, and layout?
8. Can I insert a Quranic verse with one keystroke, or do I copy-paste from another tool?

If an editor passes 6+ of these, it's actually usable for Arabic writing. Most pass 3 or 4.

Where each major editor lands

Based on my testing as of May 2026:

I'm obviously biased. But the table is also what I'd write if I were a third-party reviewer with the same testing methodology, because the comparison is on observable behavior, not marketing.

Where Nuss falls short (honestly)

To stay credible, here are the things Nuss isn't good at yet:

• Real-time collaboration. Notion and Google Docs let multiple people type simultaneously. Nuss is single-user as of May 2026. If you need live co-editing, we're not the right fit.
• Mobile experience. Nuss is web-first; the mobile site works but isn't as polished as desktop. Native apps are on the roadmap, not shipped.
• Templates. We have a few. Google Docs has thousands.
• Brand recognition. When you tell your supervisor you wrote your paper in Nuss, you might have to explain what it is.

These are real tradeoffs. They matter for some people. For most Arabic writers and researchers, what matters more is that the editor works with their language instead of against it, and that's the part we got right.

The takeaway

Right-to-left is not a CSS property. It's a deep architectural commitment that almost no Western-built editor has actually made. If your daily work is in Arabic, this commitment is the single biggest variable in how productive your writing setup is.

You can keep wrestling Google Docs. It works. Many people do. But the choice is yours: every word you write in a fight-against-you editor is a few seconds of your attention spent on tooling instead of thought. Over a thesis, that's days. Over a career, it's a meaningful slice of your life.

If you want to feel what an Arabic-first editor is like, try Nuss, the free tier doesn't ask for a credit card. If it doesn't feel different within ten minutes, close the tab and forget I said anything.