Files with Right-To-Left text (like Hebrew) is very hard to edit.
The view is correct but when I type, the place in which a letter is injected into the text is wrong and is not under the cursor. It seems that when I stand at the beginning of a line and click N times on the right arrow the cursor will move N letters to the right but then typing something will inject the letter N letters from the right (and not N letters from the left which is where the cursor is).
Rtl text isn't supported for now.
Until the proper support is added, will it be helpful to always force ltr rendering with
.ace_line {
direction: ltr;
unicode-bidi: bidi-override;
}
to make it editable?
merging this into https://github.com/ajaxorg/ace/issues/182
Is there a reason not to put
.ace_line {
direction: ltr;
unicode-bidi: bidi-override;
}
in the core CSS? (So that each person doesn't have to make the change)
I wanted to check with someone who reads Right-To-Left text language if this is really useful or just makes reading very hard.
Testing it with
.ace_line {
direction: rtl;
unicode-bidi: bidi-override;
}
doesn't look very promising.
Hm, well, on our hebrew site (for Khan Academy), the Hebrew team using it reported the RTL-ness of the code as a bug, so it seems like they expect code to be LTR.
Hmm, this seems to be against @eyalfink's statement that The view is correct
I've added it in #1716.
Pamela, Can you share a link or elaborate?
The current status I see is that I can view and read the text since it is
formatted correctly (RTL) but when trying to edit the inserted char is not
in the right place (not under the cursor).
On Fri, Dec 6, 2013 at 10:11 PM, Harutyun Amirjanyan <
[email protected]> wrote:
Hmm, this seems to be against @eyalfink https://github.com/eyalfink's
statement that The view is correct
I've added it in #1716 https://github.com/ajaxorg/ace/pull/1716.โ
Reply to this email directly or view it on GitHubhttps://github.com/ajaxorg/ace/issues/1429#issuecomment-30025302
.
I'll elaborate:
We are using the ACE editor on Khan Academy for JavaScript, and we have a Hebrew language site:
https://he-il.khanacademy.org/cs/programming/intro-to-programming/p/sneak-peek-making-an-awesome-program
I got a bug report last week from the Hebrew team that said: "1) The programming window to the right is RLT and should be LTR ( example attached)."
So I added the CSS to make it LTR.
I will clarify with them to make sure that is what they wanted. I do not have a lot of experience with Hebrew programmers and do not know what they generally expect.
This is what shouldn't be done actually. Before this we (on Wikipedia) had chance to see actual RTL text (Arabic script) but couldn't edit it properly but after this we can not even read the text in order to maintain or edit the Arabic.
CodeMirror does better on RTL, replicating that what CodeMirror does in this situation is what should be done instead. May looking at this helps.
Sorry for mishandling, this issue. Apparently issue reported to Khan Academy was only about direction: ltr;
on the editor root element.
In https://github.com/ajaxorg/ace/commit/927bf936daf41ef2164592c89f598d590fa98dac i removed bidi-overwrite but kept direction: ltr;
for now.
@ebraminio is this ok until we implement proper bi-directional support?
Seems good. Thank you
The direction: ltr
changed the direction of lines BUT the cursor's direction didn't change(see the image) while writing the text, they written from right to left but the cursor moves from left to right!!!
Is there any hack to fix this?!
I have a similar problem like @noise2:
Same issue as @thedod for me too. If I have mixed Hebrew and English it's going crazy, even when I copy paste it from elsewhere..
Can't you just ditch Ace and move to code mirror
Dear @nightwing
I am using RStudio IDE for the R language, which relies on Ace.
I am interested in having Hebrew supported in Ace. Specifically, the Hebrew (and Arabic) speaking community needs the editor to support a dual mode model where the Hebrew would be right to left, but the (R) code would be left to right.
I am willing to try and raise funds to financially support the addition of this feature. Could you (or someone else in the community) be willing to take this on themselves?
Thanks,
Tal Galili
Has there been any progress on this among the Ace contributors, @nightwing? We're using Ace for our own coding platform and some of our users need bidirectional editing. It would be useful to know if a timeline exists for adding support for it in Ace so that we can give them proper customer support.
We ran some basic testing associated with basic editing capabilities in ACE in the context of Bidi (Arabic / Hebrew) text. The results are listed in a file attached hereafter.
BidiIssues_ACE.pdf
My team is working on resolving those issues. As soon as code is ready pull request will be issued.
Very exciting, thank you for the update @tomerm !
@tomerm, great that you are working on this. As said two years ago here, I think having a look at this commit would help you. The issue here is not just about complexity of RTL text editing, I guess for the first step you should fix the assumption of Ace on text having fixed size, try to paste this LTR indic script text (gujarati, actually) on Ace and CM and highlight third part of the line by double click:
"เชเซเชเชฐเชพเชคเซ" "เชเซเชเชฐเชพเชคเซ" "เชเซเชเชฐเชพเชคเซ" "เชเซเชเชฐเชพเชคเซ"
Ace:
CodeMirror:
@ebraminio the main root cause for the observed issues is in fact that ACE does not leverage built in support of browser for cursor position / movement etc. Instead ACE provides its own cursor (basically draws it and manages its movement during interaction with end user). As a result very intimate correlation between buffer (storage) and display which is crucial for Bidi text display is violated.
ACE is not alone who made such a decision. Many other web based rich text editors decided to implement their own essential support for cursor position / movement / selection etc.
You are correct by saying that text width is one of the critical parameters for cursor logic. However much more essential one is correlation between typing order (or chronological order) of Arabic / Hebrew characters in the storage (buffer) and their display order. This correlation is guided by UBA (Unicode Bidi Algorithm) - http://unicode.org/reports/tr9/. There are multiple implementations of UBA in many programming languages (those implementations are often called "Bidi engines"). Obviously OS / browser have built in one. For our purposes we may need to use JS implementation of Bidi engine.
CodeMirror is in our focus as well (due to its usage in Jupyter Notebooks - jupyter.org).
@tomerm, great plan. I hope however you find some tricks to avoid JS side bidi implementation and reusing brower logic for that as some edge cases exists on browsers themselves that they are doing that not in a very expected way, like this bug.
One of the best implementation I've seen yet so far is Microsoft Monaco which when I left this comment on Atom it was not open source but now fortunately is, I hope that would help your efforts here.
I think you've solved it but I tell it just for others ;)
Not a full solution,
but the following google font:
https://fonts.google.com/?category=Monospace&selection.family=Cousine&subset=hebrew
is a hebrew monospace font and using it like that:
.ace_editor, .ace_editor *
{
font-family: 'Cousine', monospace !important;
font-size: 12px !important;
font-weight: 400 !important;
letter-spacing: 0 !important;
}
makes the editing in hebrew much better.
@ebraminio the fix was submitted via PR #3137 would you be reviewing the code ? Should we attract somebody else's attention ? Thanks a lot for the guidance.
Hi guys.
One question!
How many years should pass for fixing this issue?
@sharifzadesina we are determined to drive this to a closure asap. Obviously we depend on community timely code reviews. Fully functional solution was shared via #3137
Please fix it :)
@bentalgad We are going in circles for some reason. Fully functional solution was shared via #3137. Do you happen to know who can / should review the code of fix ?
Oh don't know. does it mean i can some how implement this fix on my atom?
@bentalgad you can definitely download the pull request (from #3137 ) and merge / adopt it locally. I believe this is what @ebraminio already did (see #3137 for more details).
BUMP.
So can we notify someone about this PR? It would really be great to add RTL support.
Thanks.
@talgalili the actual pull request is in #3137 . If I understand correctly it should be @nightwing who will eventually review and deliver it. We addressed all comments @nightwing provided on Jan 4th 2017. On March 1st 2017 @lyudmil suggested his help in merging the pull request. However @nightwing has not related to this offer.
Hi @tomerm
I see you've got some attention from nightwing:
https://github.com/ajaxorg/ace/pull/3137
I hope you can address them and that this can be added in the near future.
Thanks!
https://github.com/ajaxorg/ace/pull/3137 is merged now, please report any followup feature requests or issues that you find.
The issue pointed out by @ebraminio in the comment of Aug 2, 2016 (https://github.com/ajaxorg/ace/issues/1429#issuecomment-236819782) is still present: try putting "เชเซเชเชฐเชพเชคเซ" "เชเซเชเชฐเชพเชคเซ" "เชเซเชเชฐเชพเชคเซ" "เชเซเชเชฐเชพเชคเซ"
on a line and selecting individual words by double-clicking. Or go to end of line and look at the cursor position. Or try inserting line breaks. Etc.
Hello,
I'm confused with the RTL support at the moment. Is it explained somewhere in documentation?
Is there something to set, in order to get Ace support RTL editing?
I tried to follow the issues and searched the docs but couldn't figure it out.
Can anybody point at some documentation on what needs to happen for RTL support to work? Like others above in this thread, I've been searching the docs and several posts for a while and I still can't figure out whether RTL support is there or not. It all just goes in circles without any sort of documentation that I can dig up - just unresolved issues.
The Kitchen sink has RTL as a checkbox option but that doesn't seem to work either.
I realize some of this is probably my own ignorance on how RTL/LTR switching works, but that's why it would be nice to have some source of what support there is and what is required to make it work.
Any direction appreciated...
@RickStrahl,
thank you for trying to fix this issue, here is a simple way to see how RTL support should look like:
https://github.com/gollum/gollum/issues/1314
Hopefully it will be useful to you!
BTW. Gollum plan to switch to Ace editor in their next version, and proper RTL support is quit important to them, see here (press Ctrl-f and search for "RTL"):
https://github.com/gollum/gollum/issues/826#issuecomment-44373680
Thank you!
Most helpful comment
Can anybody point at some documentation on what needs to happen for RTL support to work? Like others above in this thread, I've been searching the docs and several posts for a while and I still can't figure out whether RTL support is there or not. It all just goes in circles without any sort of documentation that I can dig up - just unresolved issues.
The Kitchen sink has RTL as a checkbox option but that doesn't seem to work either.
I realize some of this is probably my own ignorance on how RTL/LTR switching works, but that's why it would be nice to have some source of what support there is and what is required to make it work.
Any direction appreciated...