Hello,
I am new to this package, so please forgive me for this trivial issue.
When using rtl direction for textarea, and when textarea shows line numbers, the expected placement of linenumbers is at the right, while I cannot see any option to control that and these are placed at the left.
I believe the placement of line numbers should be automatically be set based on the direction of the widget.
Any hint how to do this? or is it missing functionality?
Thanks!
Alon
Hi Again,
I also have troubles with scrollbars, I get right and left scrollbars at the same time instead only left.
If you like you can access[1] to see an example.
When index.he.css body’s direction is rtl and you select the last examples (long one), you will notice left and right scrollbars and line numbers at left.
Using firefox interceptor modify the direction to ltr and you will see that behaviour is correct.
There is also a scrollbar at the oneliner editor, which should not be there, again, this goes away when setting ltr direction.
Thanks!
We do not yet have support for putting the gutter on the right of the editor, and setting direction: rtl on the editor elements is also not supported yet (as you found out – it messes up the scrollbar).
You will probably get better results if you use the code in the direction branch on github. Unfortunately, we don’t currently have the programmer-power needed to land this work on the master branch, and that branch is not being updated. Eventually, I hope to find time (or sponsorship money) to merge and improve RTL support.
Thanks for the answer, I did not notice it before.
Is there any option to just align the text properly? See example here[1], at the bottom box there is diagonal little arrow, press it and see that box is becoming multi-line, you will notice that there is an overflow (text beginning at where it is actually hidden), I guess this overflow is at the size of the line number addition or the size of the new scrollbar that is added. Maybe do not align to 100% of space but to 95% as temporary workaround.
Thanks!
The link you gave renders with the wrong encoding for me, making it hard to see what is going on.
You could try adding CSS hacks to work around the problem you describe, but this isn’t something I’m working on at the moment.