minimal RTL support for single lines

version=0.1.0-main+4ac9610b

right now this is how
بسم الله الرحمن الرحيم

will look in ghostty

and like this in konsole

there are multiple issues
first the characters shaping is wrong
in Arabic and Persian each glyph changes shape depending on the glyph behind it and after it for example:

ignore the "e)" it is there just to make the Arabic text left aligned

e) ي + ز + ن
the first letter is "ي" and the last is "ن"
should be shaped like this
e) يـ + ـز + ن
not like this
e) ( ي + ز + ن ) or (ي + ز + ـن)

the second issue is glyph order in each word
e) علي (correct)
even if the first issue was fixed the text will look like this
e) ﻲﻠﻋ (wrong)

the third issue is word ordering, I don't think there is one correct answer there are two options
the first is to not change anything
firstWord secondWord
or make it like konsole
secondWord firstWord

I'll say up front I'm not very familiar with RTL languages on computers. I have read the full RTL/Bidi terminal spec here and I don't currently plan on supporting that in the near term since it requires a very significant amount of effort that I'm not ready to put forward. One day, I'd like to support this.

If what you're suggesting can be resolved in a renderer/shaping-only way then I think we can at least get partial RTL support, so I'll keep this open for that. 😄 More research necessary.

Thank you for the example text and screenshots, this will help significantly.

Hello. I meant to open an issue regarding this but found this one. I am using the 1.0 Dec26 version of Ghostty. I am on MacOS.

The shaping seems to work fine. All the letters are shaped properly. Problem is they are the wrong order. If I were to guess, they are probably passed to the shaper in the opposite order of what they should be. I don't know what shaper you're using, but HarfBuzz and rustybuzz want the text in the logical order and they give you the rendering order from left to right.

minimal example

Here is how it looks (correctly) in Terminal.app

same on fedora 41
kitty(right) ordering the letters correctly:

Until the RTL Support added in the future I encourage you to use bicon with ghostty, or use wezterm "it supports RTL very will

Could I suggest a slight tweak to the wording of the features page related to this? That page currently says:

Certain languages like Arabic and Hebrew are also rendered correctly (LTR only).

which is a little like saying "English text renders correctly (backwards only)." I think it would be clearer to say something like:

While only left-to-right text is supported, characters from RTL scripts including Arabic and Hebrew are correctly clustered and rendered.

@mjec

@mjec Happy to make that change, would you be open to PR-ing it to the website repo?

Could I suggest a slight tweak to the wording of the features page related to this? That page currently says:

Certain languages like Arabic and Hebrew are also rendered correctly (LTR only).

which is a little like saying "English text renders correctly (backwards only)." I think it would be clearer to say something like:

While only left-to-right text is supported, characters from RTL scripts including Arabic and Hebrew are correctly clustered and rendered.

Ghostty does not render characters in RTL scripts correctly, though. They are rendered backwards. Would you say olleh is a correct clustering and rendering of hello? It would be much clearer to say that Ghostty does not support RTL scripts (like Arabic and Hebrew).

@mitchellh

Can't some grant be secured from the rich Gulf states? UAE invests so heavily in new technology.

@mitchellh Perhaps if you try to reach out, they'll pay for adding this feature. I have no idea how to do that though. Perhaps through a collaboration with someone at MBZUAI.

Until the RTL Support added in the future I encourage you to use bicon with ghostty, or use wezterm "it supports RTL very will

Can you use bicon with ARM macOS? The last time I checked it didn't work.

a) Please do not ping maintainers.

b) Ghostty is an all-volunteer project and nobody here is interested in financial gains. Mitchell doesn't particularly need oil money only made possible with indentured labor, either. Perhaps instead of capital, lend us some hands instead.

if anyone is interested
already did a fix on the font/shaper side
#11079
here is the build of that pr if you wanna quickly test it (built for macos - universal)
https://github.com/DiaaEddin/ghostty/releases

@DiaaEddin

if anyone is interested
already did a fix on the font/shaper side
#11079
here is the build of that pr if you wanna quickly test it (built for macos - universal)
https://github.com/DiaaEddin/ghostty/releases

Yes, that looks interesting! The pull request is by @DiaaEddin , not by @DiaaNoon , I'm a bit confused.

if anyone is interested
already did a fix on the font/shaper side
#11079
here is the build of that pr if you wanna quickly test it (built for macos - universal)
https://github.com/DiaaEddin/ghostty/releases

Yes, that looks interesting! The pull request is by @DiaaEddin , not by @DiaaNoon , I'm a bit confused.

yeah sorry about that, DiaaNoon is my work account,

@DiaaNoon

Working local implementation of the renderer/shaping-only scope from this issue. Tested with cat arabic.txt, mixed Latin/Arabic prompts, and against Apple Terminal output.

Stack: uucode bidi runtime fields, itijah (pure-Zig UAX #9) + visual run iterator with LTR fast path, HarfBuzz + CoreText consume run direction, renderer applies UAX #9 reorder per row, cursor + selection mapping for mixed-direction lines. 4 PRs ready on stacked local branches.

Vouch request with screenshot: #12624

Happy to coordinate with @DiaaNoon on #11079, willing to take it over, fold approaches together, or rebase mine onto theirs, whichever the maintainers prefer.

@ibrahimhajjaj

@ibrahimhajjaj it would be good if you and @DiaaNoon could collaborate and come up with a unified approach.

@ibrahimhajjaj

@ibrahimhajjaj could you share your fork? Happy to work together on this on #11079. Regarding cursor, it was left out of this PR intentionally per Mitchell's preference in the 2024 discussion on #1442, and will be addressed in follow-up work. wdyt?

@DiaaEddin

@DiaaEddin fork's at https://github.com/ibrahimhajjaj/ghostty

four stacked branches:

bidi/run-iterator: uucode bidi fields, itijah dep, run splitting at level boundaries, ltr fast path (skips bidi entirely on rows with no strong-rtl cells), bidi-scan bench
bidi/shaper: harfbuzz + coretext consume run.rtl
bidi/cursor-selection: cursor visual mapping for mixed-direction lines
bidi/rtl-justify: per-row uax Charsets #9 logical to visual reorder at the renderer (cell.x stays logical in the shaper) + rtl-justify config flag

itijah is yours and it's the dep under both stacks, glad it exists. the architectural difference is mostly where the visual reorder happens. your run iterator emits visual order, mine keeps the iterator logical and does logToVis at the renderer. mine has the ltr fast path. tested on macos arm with al-fatihah verses, lam-alef, mixed latin/arabic, right-justify all working.

i'll leave the two stacks parallel and let mitchell pick the architecture when he gets to it. wdyt?

re cursor: keeping it on its own branch as v2 since you confirmed mitchell scoped it out. not bundling it into v1.

Thanks for sharing the branches. Went through them, really nice work.

A few notes from comparing the approaches: the shaper side handles mark anchoring a bit differently. Your branch mirrors clusters, while #11079 tracks per-cluster anchors. Your LTR fast path was a good idea too; I added the same general optimization at the itijah layer in 0.2.1 via hasStrongRtl and an allocation-free pre-scan inside getParEmbeddingLevels, so callers can benefit without each integration adding its own check.

Parallel stacks sound fine to me; that gives Mitchell both shapes to compare when he gets to it. Your cursor-selection and rtl-justify branches cover exactly the terminal-side scope deferred from #11079. Happy to look at collaborating on those follow-ups once #11079 lands.

I’m seeing the same issue with Arabic in Ghostty: Arabic should render right-to-left, but it is currently displayed left-to-right / in the wrong visual order.

This makes Arabic command output, filenames, and Arabic text in terminal apps difficult to read. Other terminals such as Terminal.app render the same Arabic text correctly, so this appears to be the RTL/BiDi terminal-surface issue tracked here.

Adding this as another Arabic-language data point and to ask that proper RTL/BiDi support be prioritized.

refactor!: rename to Dekho Suno Jaano

Navigation Menu

Repository navigation

minimal RTL support for single lines #1442

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

minimal RTL support for single lines #1442

Description

Activity

mitchellh commented on Feb 2, 2024

asibahi commented on Dec 27, 2024

eifr commented on Dec 28, 2024

motaz-shokry commented on Dec 29, 2024

mjec commented on Dec 30, 2024

mitchellh commented on Dec 30, 2024

Flimm commented on Dec 31, 2024

21 remaining items

NightMachinery commented on Sep 27, 2025

NightMachinery commented on Sep 27, 2025

pluiedev commented on Sep 27, 2025

1saifj commented on Feb 15, 2026

DiaaNoon commented on May 1, 2026

Flimm commented on May 2, 2026

DiaaEddin commented on May 2, 2026

ibrahimhajjaj commented on May 9, 2026

jcollie commented on May 9, 2026

DiaaEddin commented on May 9, 2026

ibrahimhajjaj commented on May 10, 2026

DiaaEddin commented on May 17, 2026

Saiaf25 commented on Jun 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions