Turn off RTL for syntactical characters in bidi lines

[otseng]

I am editing a document that has English, Hebrew, and Arabic in it. The cursor movement is based on the language the cursor is on so it jumps in different directions. Inserting and appending text is also unpredictable.

For example, if a line is:
Peace | שלום |
and I paste at the end of the line :
سلام
It will become:
Peace | שלום | سلام
I want it to be:
Peace | سلام | שלום
Editing the line is also difficult.

Here is a similar request on SO:
https://stackoverflow.com/questions/54538844/disable-right-to-left-editing-in-vscode-in-mixed-language-files

I'd like the ability to easily turn on and off RTL while I'm editing or have the ability to override RTL for the entire document.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• How to add an RTL layout for editing Hebrew & Arabic documents (Not code) (#45180)

[jb6]

@alex @otseng Hi , I am facing the same issue. I need to use both English AND Hebrew AND parenthesises all the time but when you mix LTR and RTL languages in the same line, the parenthesises and word order are swapped.

This is what I want to achieve (this is a screenshot from Textmate , the only editor that makes things look right ) :

This is what you get on vscode:

Many editors can't handle mixing RTL and LTR languages ,even worse if you add parenthesises. (Sublime and Atome can't handle it either). Even the display on Github here is swapped/wrong (forcing me to screenshooting the desired display here) .

Look what happen when I copy paste the exact line from what is displayed on Textmate here :
Tools :
(שלום|היי|בוקר טוב) {(מר|גב) מרקוס}

--> the order is totally swapped.

[alexdima]

Today, the text layout is delegated to Chromium in these cases. The layouting algorithm in Chromium is, AFAICT, correct.

The characters: (, ), {, }, | have the directionality defined as DIRECTIONALITY_OTHER_NEUTRALS, which I believe means they take the directionality of their context, so e.g. | placed inside RTL text becomes RTL, | placed in LTR text becomes LTR.

I think your feature request is that certain syntactical characters can be customized and be forced RTL.

[vscodebot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[jb6]

yes @alexdima this is what we need .
To upvote this request, one just needs to like the issue? else how can we upvote this request out of the backlog ? thx

[vscodebot]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[zspitz]

@jb6 Your second screenshot looks fine; you might want to fix that.

[jb6]

@zspitz not sure what you are saying here. My second screenshot is NOT fine. yours is not fine either by the way. I want to write what is written in my first screenshot (textmate) in VSCODE and it was not possible on VSCODE. In your screenshot the order of the words is swapped and in my second screenshot the parentheses are misplaced. @alexdima

[zspitz]

@jb6 Yes, you're right. I was focusing on the word order, but the problem is in the braces.

[zspitz]

@alexdima

The characters: (, ), {, }, | have the directionality defined as DIRECTIONALITY_OTHER_NEUTRALS, which I believe means they take the directionality of their context, so e.g. | placed inside RTL text becomes RTL, | placed in LTR text becomes LTR.

That explains everything except the leftmost opening parenthesis and the rightmost closing curly brace, which still appears to resolve to LTR.

AFAICT the first step in the Unicode Bidirectional Algorithm is to split the text into paragraphs, and assign a direction to each paragraph based on the first strong character (see 3.3 Embedding Levels and 3.3.1 The Paragraph Level in the Unicode Bidirectional Algorithm spec.

VS Code (as of version 1.42.0-insider) still has no notion of an RTL paragraph. For example, if I understand correctly, the following paragraph:

should be identified as an RTL paragraph, which means both the space after the letters and the period should be considered part of the RTL run:

. DCBA

And the first parenthesis in jb6 's text above should be treated the same way -- the first strong character (א) is RTL, so the paragraph is an RTL paragraph, and thus the neutral first parenthesis should resolve to RTL.

Something similar is happening to the end brace: it's being treated as LTR even though it's a neutral following an RTL run.

---

NB. Since the first parenthesis is the opening bracket of a bracket pair within an RTL run, the visual direction is reversed. IOW, even though the LTR would look like this:

(abcd)
123456

a bracket pair in an RTL direction, causes the first character to look different:

(DCBA)
654321

The solution would be to define the paragraph as RTL, and everything else should fall into place.

@jb6 Does this seem correct to you?

[jb6]

Sorry for not replying before @zspitz @alexdima. @zspitz thanks your solution sounds good but I am not sure it will work well if you want to Mix 1) DIRECTIONALITY_OTHER_NEUTRALS , 2) RTL and 3) LTR languages in the same line of code. It would great to have the user do a sort of casting to DIRECTIONALITY_OTHER_NEUTRALS characters according to whether he wants immediate LTR or RTL after a DIRECTIONALITY_OTHER_NEUTRALS character. AFAICT was supposed to do this but according to what @zspitz wrote, it is not still doing the job for the use cases we need. @alexdima any idea why ? Was wondering also what was the status of this task ? if you could tell me that would be great.

[selimachour]

Hi, I'm doing regular expressions on mixed content of (arabic, latin and numbers). It drove me completely crazy until I started using sublime for that. I would love to do it in vscode :)

[jb6]

Sublime sadly does not work for what I xq want to do, aka mix parenthesis with Hebrew (RTL language). Can't wait to have vscode for this.

…

On Tue, Feb 18, 2020, 12:15 Selim Achour ***@***.***> wrote: Hi, I'm doing regular expressions on mixed content of (arabic, latin and numbers). It drove me completely crazy until I started using sublime for that. I would love to do it in vscode :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#83365?email_source=notifications&email_token=ABSYPPTTLNNJMTRCL65L67TRDO7ORA5CNFSM4JFPHS72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMBS7MQ#issuecomment-587411378>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSYPPTRTWTVCVN6CCH457DRDO7ORANCNFSM4JFPHS7Q> .

[aradalvand]

No updates on this one?!
This makes any line of code that has both English and RTL languages in it completely confusing.
The behavior should be just like Visual Studio, the current behavior of VSCode is incorrect.
Wish you'd give a little more attention to this issue.

[raviganwal]

I did it by removing English text and just editing Hebrew text at first. once Hebrew is edited then I added the English text again. here is the output video.
https://user-images.githubusercontent.com/22388017/157378941-17eaa868-474e-4374-9553-4465598e3758.mov

[grabani]

Can you please provide a status on the resolution of this issue? Thanks

[szjiangfan]

try Sublime 2。version 2.0.2