Bug 451789

Summary: navigating arrow keys while on RTL keyboard layout stuck on endless loop
Product: [Frameworks and Libraries] frameworks-ktexteditor Reporter: Shual Kravot <as.afgre.enberg>
Component: generalAssignee: KWrite Developers <kwrite-bugs-null>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Shual Kravot 2022-03-22 10:16:56 UTC
SUMMARY
***
when editing RTL text  (right-to-left keyboard layout; languages such as hebrew, arabic, urdu),
empty raws are still considered LTR. Consequently, arrow keys are contradicting, causing the cursor to get stuck in an infinite loop.
***


STEPS TO REPRODUCE
1. add RTL text in line #1
2. add empty line at line n+1 (line #2)
3. add another RTL text at line n+2 (line #3)
4. place the cursor at the end or middle of line #3 (e.g. press HOME key on line #3)
5. press the LEFT arrow repeatedly.
example text (copy > paste into Kate, beteen the "-----" lines -- the empty line in the middle is needed):
--------
שורה ראשונה מילה נוספת.

שורה שלישית מילה אחרונה.
---------
OBSERVED RESULT
6. The cursort will arive to end of line #1, and to line #2
7. From line #2 the cursor will go back to line #1.

EXPECTED RESULT
The cursor was supposed to continue to next lines / text.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:   all versions. 
KDE Frameworks Version:  ? 
Qt Version:  ?

ADDITIONAL INFORMATION
Why is that happening:

In RTL context, LEFT means "go forward", and "right" means "backwards".
In LTR it is the opposite.
When pressing LEFT key, the cursor start of the RTL line "forwards" until it arrives to line #2.
However, line 2 is empty, thus automatically set to LTR (regardless of previous/next line, or previous RTL settings).
in LTR contextx, LEFT key means "go forward", so the cursor moves BACKWARDS to previous line, #1,
never reaching line #3.
ad infinitum.

Same happenes with CTRL+Arrow keys.
Same behavior happens in the other direction (End of text to Beginning)


Possible solutions:

Option  1.
Define the RTL / LTR property of an empty line by its preceding line's directionality
regex= ^[א-ת].*?\n(<dir=RTL>)

Option 2.
Retain cursor order when arrow keys are pressed.
I.e. when starting a sequence of arrow keystrokes (or ctrl+arrow),
keep the same logical direction until a different key is pressed.

3. let user set LTR/RTL direcetionality for the whole passage. (e.g. facebook setting RTL /LTR by the first letter of the document.



Example #2: correct behavior (even if illogical)
In a single, mixed sentence, the cursor continues its initial direction, in spite of "illogical" contradition inside the English passage.  This is a correct behavior [considering the natural limitations of plaintext editors].
Place the cursor at the beginning of the line, and press multiple LEFT arrow keys (or SHIFT+LEFT).
The corsor will arrive correctly to the end of the sentence.
 1. מילה, ועוד אחת. inline LTR text here, ואז נוספת סוף שורה.

1. Copy the following text to a text editor / text box,
2. place cursor at beginning of the line.
3. press multiple LEFT keys (or SHIFT+LEFT).


Example #3:
Moving between RTL to LTR lines:
שלום לבוא שבת how many
lines must a man להמשיך ללכת


Expected behavior:
When pressing an arrow key (or any arrow+modifier), cursor jumps to each "next" word, until end of text.

Actual behavior:
When starting in a RTL text,
cursor traverses CORRECTLY & logically from left to right, until an empty (or LTR) line.
At the empty / LTR line, cursor's direction reveresed and it goes backwards to previous line.
Comment 1 Bug Janitor Service 2022-03-22 17:57:24 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/343
Comment 2 Christoph Cullmann 2022-03-22 19:12:51 UTC
Git commit b1c4d600e05ff6899a9a58e9e0456e30b706e29b by Christoph Cullmann, on behalf of Waqar Ahmed.
Committed on 22/03/2022 at 18:50.
Pushed by cullmann into branch 'master'.

Improve cursor movement with RTL text in doc

Currently, empty lines are always treated as LTR which is not a good
default to fall back on always. Instead if the line is empty, we can try
to scan nearby lines and choose a direction. This way it is possible for
RTL users to also navigate the text with keyboard.

M  +39   -14   src/view/kateview.cpp
M  +1    -1    src/view/kateview.h
M  +1    -1    src/vimode/modes/modebase.cpp

https://invent.kde.org/frameworks/ktexteditor/commit/b1c4d600e05ff6899a9a58e9e0456e30b706e29b
Comment 3 Shual Kravot 2022-03-26 14:07:07 UTC
1. It's not only on empty line:
this bug will happen with every line that do not contain text.
e.g.
טקסט
====
עוד טקסט


The scope is larger than that:
any non-text between RTL texts will be still consider LTR.
In the same example, the "=====" line will be displayed on the left side,
while the texts will be aligned to the right,
e.g.
|               טקסט|
|===                  |
|         עוד טקסט|

(Althogh, this is just cosmetics; The main bug blocks functionality.)