-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Visual Studio Code right-to-left test #4
Comments
@nathangibson RE # 6 under Selecting Text -- What is the good answer here? I think cursor movement and selection have to work the same way, and having the right arrow always move the cursor right would result in a discontiguous selection at the border between LTR and RTL, but which would visually appear contiguous. I think the better solution is to encourage thinking of the right arrow movement as "advance the cursor position logically forward", and everything else falls into place. |
@zspitz Thanks for the comment. Partly this depends on whether the "base direction" of the line/paragraph can be set or automatically recognized in the application. (See https://www.w3.org/International/articles/inline-bidi-markup/uba-basics#context.) As far as I can see, neither is possible in Visual Studio Code. If you have have an entire line or paragraph of RTL, pressing right to go left is simply confusing and counterintuitive. If you have BiDi text, there is a case to be made for the arrows to move the cursor in opposite directions within a run of opposite-direction text. This means that, like you said, the arrows would move the cursor opposite directions inside RTL text if it is surrounded by LTR text, but also that they would do so inside LTR text if it is surrounded by RTL text. That is how MS Word for Mac handles the situation--it depends on the base direction of the line. Other programs handle this differently, keeping the cursor movement always directly linked to the left/right of the arrow buttons, regardless of whether it is inside opposite-direction text. E.g. TextEdit for Mac. To me this is more natural and intuitive. The only disadvantage is if you're trying to select part of an RTL text run together with only part of an LTR run in less than a full line. Then you would have what you called
It seems to me a small price to pay for having intuitive cursor movement. But I would be interested in hearing more opinions from RTLers about this. For what it's worth, Mellel which is a word processor specifically designed for RTL and BiDi text splits the difference. Cursor movement follow arrow direction unless you're selecting text, in which case it keeps the selection logically but not visually contiguous. (This would go against your principle of having cursor movement and selection working the same way.) Regardless of how the BiDi issue is resolved, there is in any case a problem with how VSC handles RTL text since no base direction can be set or detected. This means that RTL text will always have cursor movement in the opposite direction of the arrows, regardless how large the block is. E.g., You have an entire line or paragraph consisting of only RTL text. But within that line or paragraph you always have to go left in order to go right, and vice versa? Very confusing. Or you're at the beginning (right side) of an RTL run of text and in order to enter the RTL text you have to press the right arrow button. |
Is there anything I could help with to test and finally get the RTL support merged into the next release, please? |
@mohataher That would be so great! There are several open issues for RTL/bidi text editing in VSCode. I'm not a developer, but as far as I can see, achieving good bidi text handling would involve several different features, including:
It looks like (3) has been assigned to @alexdima and @deepak1556 here microsoft/vscode#78867 and is scheduled for this month's milestone. Maybe you'd want to reach out and check whether they'd like help with that one or with this related issue from the backlog: microsoft/vscode#83365 ? Also in the backlog is this issue relating to (1) above: microsoft/vscode#65648. Otherwise, there are some general issues with recent activity and good discussion about what might be involved in making RTL a less painful experience in VSCode: microsoft/vscode#86667 and microsoft/vscode#11770. I would agree though with the concerns expressed about inserting Unicode control characters -- things could get really unpredictable, especially if the control characters are in source code that has other RTL handling (such as HTML). So maybe reach out and then see what's doable for you? Really appreciate the support! |
Name of app/URL of website
What app or website are you testing?
Visual Studio Code
Are you testing a particular field or type of document?
Plain text
Desktop (please complete the following information):
TESTS FOR PLAIN TEXT EDITORS
Copy this text into your text editor, answer the questions, and then paste it back here. Put an x inside the [] to answer the questions below. Feel free to add screenshots in the issue.
TEXT DISPLAY
Word 1, 2 الكلمة, word 3
كلمة 1، word 2, كلمة 3
-[] Yes
If No, what happened?
The numbers on the second line still display left-to-right.
LINE DIRECTION
هذه الكلمة.
-[] Yes
If No, what happened?
Not available from menus. Period appears on the right.
هذه الكلمة.
-[] Yes
If No, what happened?
Not available from menus.
هذه الكلمة.
-[] Yes
If No, what happened?
End of line is on right.
SELECTING TEXT
هذه الكلمة.
-[x] Yes
If No, what happened?
هذه الكلمة.
-[] Yes
If No, what happened?
Within RTL text the right arrow moves the cursor left and vice versa.
هذه الكلمة.
-[x] Yes
If No, what happened?
هذه الكلمة.
-[x] Yes
If No, what happened?
هذه الكلمة.
-[x] Yes
If No, what happened?
هذه الكلمة.
-[x] Yes
If No, what happened?
Yes, but the arrow keys are reversed.
Other Notes/Screenshots
Relates to the following open issues in the VS Code repo:
See especially microsoft/vscode#86667
Also
microsoft/vscode#11770
microsoft/vscode#65648
microsoft/vscode#83365
microsoft/vscode#4994
microsoft/vscode#65855
The text was updated successfully, but these errors were encountered: