Ahalan Zayed,

I have just commited a patch to Kate (it will be part of KDE 4.1) which forces the line number widget to be on the left. 

The next step will be determinate the LayoutDirection of each line, automagically (more LTR chars the line will have direction=ltr, more RTL chars, the line will have direction=rtl).
Then I will continue and draw RTL lines aligned to the right.
Finnally I will give the user an option to change the layout direction. 

If have ideas about the implementation, please append them to this bug. 

One thing I don't understand is where to put the line numbers widget. I do not want to put it on the right for RTL desktops, because it will mean that when editing code your head will explode! :)
Changing the location of the widget according to the direction of the current line, is not ideal, since on document with lines that have different direction, this will cause the widget to move from the right, to the left too much.

Created attachment 23273 [details]
Kate with Hebrew UI, displayind a source code

As you can see, each line has a RTL direction which causes the application to
be unusable for editing code. This is my first priority.

hi Diego

The idea to let the handling of text (i.e at least BiDi staff) is independent of the main window.  

The line numbers widget should be always in the left side. So yes you did the right thing thank you. 

ok, lets make it better now -

My idea is:
1) if paragraph starts with ‎ -> it's LTR for sure
2) if paragraph starts with ‏ -> it's RTL for sure
3) If you press control+shift, you are sure you want to set the direction, and you should put that char in the beginning of that line/paragraph. If a previous direction has been set - kill it.
4) If no direction has been set (see 1,2), guess it by testing the amount of chars in that line (already implemented in KDE 4.1 and above). 

This will render the text the same in notepad/gedit and Kate. However, it feel a little ugly, as we manipulate the document in invisible ways. We should also consider the GtkSourceView guys to implement somthing similar, otherwise passing text documents around is a mess.

What do you think Zayed?

Ok, let look to this issue form another angle. Let discuss this case: I use kwrite   to write an article which is in Arabic but consists some English word. Since it is in Arabic, it should be RTL mode even if I write English word in the beginning the line. Sometimes, I want to put a long English quotation about one paragraph in the article, so it nice if I can change the mode of that paragraph to LTR. After that I want resume in RTL mode. 
There for I suggest this solution:

1-The default setting is depending on the file itself. If Latin words are more  than 80%, then set the mode to LTR, else set the mode to RTL.

2-Give the user an option to change the mode of the paragraph (I prefer button and keyboard keys ) 

You only mentioned (4) out of my list. That's ok and implemented. My question is what to do when you say "ok dear kate, I know you think it's LTR, but trust me, it's RTL".

My proposal is:
Use presses control+left_shift. The kateParts adds to the paragraph the &RLO; char.

Now, when painting the katePart looks for the first char:
if it's &RLO; -> force the direction of the paragraph to RTL.
if it's &LRO; -> force the direction of the paragraph to LTR.
nothing? lets guess as we do now.

This is a "abuse" of the BiDi algorythm, and the file will open exactly the same under notepad and GEdit for example. 

I get what you mean. My case I said "Give the user an option to change the mode of the paragraph" which means exactly what you propose !! 

Regarding BiDi algorithm,  as long as we fulfill our requirements I do not care about it.  

No matter which method is used to determine LTR / RTL for any particular line, there should be a button / keyboard shortcut that lets the user switch. Naturally, the keyboard shortcut should be consistent across KDE applications.

That said, I would actually prefer the direction to be determined on a document-by-document basis, not on a line-by-line basis. That prevents having portions of a document aligned to the left edge and other portions aligned to the right.

I am in favor of the first letter determining directions as opposed to % of content. Using % of content sounds like the direction will jump around while the user is typing. However, so long as the user can override the direction and set his own, any solution is fine.

Thanks!

(In reply to comment #6)

Hi Diego,

> 
> My proposal is:
> Use presses control+left_shift. The kateParts adds to the paragraph the &RLO;
> char.
> 

The general idea sounds solid, but use ‏ (like you mentioned before) instead of &RLO;. The &RLO; character has two properties you do not want:

1) Its effect remains until the matching &PDF; character, so when you add &RLO; in this context you also need to add &PDF; at the end of the paragraph.

2) It works not at the paragraph level, but the character level: All characters between &RLO; and &PDF; are considered strong RTL chars, so any English or numbers in the range will appear reversed.

I found a flaw in adding those BiDi control chars. Lets imagine the new editor control is added to lokalize.

Now, lets assume a user right alignes by force (instead of using the guess by the system). Now the control sets the text uppon saving to &rlo; + s  + &pdf; If the original string ended with \n, the new lokalized string will end with \n &pdf; which will bork the svn commit hooks (if msgid ends with \n, msgstr should end with \n as well). The user has now no control and no way of knowing why the basic tests fail.

Shai,
Adding ‏ will not add the side effect I described before, but will not officially set the direction of the pargraph. We can decide that if the paragraph starts with that char, our guess is RTL, but that is more hacky then what I wanted. 

I assume there is no better alternative.

Diego,

Look at my previous message, again, specifically under "2)". If you use &RLO;, you will reverse any number in the localized text -- it is unacceptable long before you reach svn hooks. For the effects you want, you can use &RLE;/&PDF; instead.

Can you explain in more detail why "Adding ‏ [...] will not officially set the direction of the pargraph"? The way I see it, It will for any fully-standard-compliiant implementation, and it will for Kate if we make it.

as far as I understand (from Shosh's presentation...) is that ‎ behaves like an invisible "א", it does not change the direction of the paragraph.

Oh, yes. I keep thinking as if the whole world is plain text. If the app has set a direction for the document, a ‏ will not change the paragraph's direction, and Kate (being a part) needs to consider this also.

Oh well, then, it needs to be &RLE;. How hard is it to push the &PDF; before the \n instead of after it?

For the reference of anybody else interested, can you point to the relevant source(s)?

Is this bug still a concern? I think somewhere between Qt4.6 and KDE SC 4.6 it died without anybody noticing...

Ok, according to Shai, this may work just fine.

Since I have no idea bout RTL languages, we are depending entirely on your feedback and patches. I'll close this report assuming it's fixed. If not, please reopen. Or even better, if parts of this report are fixed, maybe open a new report to keep the size of the bug reports small.