Bug 165397

Summary: [BiDi/Unicode] Right/left arrows do not work in RTL mode
Product: [Applications] kate Reporter: Zayed Al-Saidi <zayed.alsaidi>
Component: kwriteAssignee: KWrite Developers <kwrite-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: christoph, ebrahim, elcuco, Fahad.alsaidi, justin.zobel, kde-2011.08
Priority: NOR Keywords: rtl
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Zayed Al-Saidi 2008-06-30 10:44:01 UTC
Version:            (using KDE 4.0.83)
Installed from:    Ubuntu Packages

The right and left keyboard arrows does not work properly in RTL mode. When the right arrows is pressed the cursor goes to the left and when the left arrow is pressed the cursor goes right. 

Way to reproduce this bug.

1- open kwrite in RTL mode.
2- paste this text
لبي بتيكلسشمن يتبكسب سشمنتيبسش ي
3- try to go right or left with keyboard arrows
Comment 1 Zayed Al-Saidi 2008-10-10 12:45:08 UTC
still the same in kde 4.1.2
Comment 2 Diego Iastrubni 2008-10-11 01:44:07 UTC
when the paragraph direction is RTL the arrows should switch direction. This means that the keyboard arrows do not have a logical meaning - a visual one.

Things to remember:
 * control + arrows: reverse the next/prev word skipping
 * shift + arrows: selecting should work as well
 * control+shift: selecting next/prev word should work as well

if arabic is hard to test (because of arabic shaping), I am adding a Hebrew test case (both strings will work the same way, but IMHO hebrew will be easier to debug):

אני אוכל זכוכית וזה לא כואב לי

Something I am not sure about, is what happens when an RTL paragraph is found in the middle of a LTR document. Pressing left in theory should get you to the end of the document. If you do what I suggest, you will gets stucked in the RTL paragraph in the middle of the text.
Comment 3 Dotan Cohen 2009-04-18 20:28:47 UTC
*** Bug 187411 has been marked as a duplicate of this bug. ***
Comment 4 Zayed Al-Saidi 2009-06-08 07:06:30 UTC
This is upstream bug, please see this:
http://www.qtsoftware.com/developer/task-tracker/index_html?id=254850&method=entry
Comment 5 Dotan Cohen 2009-06-08 21:09:24 UTC
> Something I am not sure about, is what happens when an RTL paragraph
> is found in the middle of a LTR document. Pressing left in theory
> should get you to the end of the document. If you do what I suggest,
> you will gets stucked in the RTL paragraph in the middle of the text.

I expect the left arrow to go left, and the right arrow to go right, independent of the language on the screen. If that gets me stuck somewhere on corner cases, so be it. The down arrow should get the user to the end of the document, not the left arrow.
Comment 6 Zayed Al-Saidi 2011-11-10 15:19:07 UTC
Just to update this bug using KDE 4.7.3 and Qt 4.7.4. 
The bug is still there with kate and kwrite. The good thing is th4at Qt has fixed this issue for qt-only applications like ReText and any qt text-input widget.
Comment 7 Christoph Cullmann 2012-11-01 15:23:41 UTC
*** Bug 279053 has been marked as a duplicate of this bug. ***
Comment 8 Christoph Cullmann 2012-11-02 22:46:25 UTC
*** Bug 172630 has been marked as a duplicate of this bug. ***
Comment 9 Christoph Cullmann 2012-11-02 22:46:42 UTC
Seems we have serious problems with this, anybody could help out with some patch?
Comment 10 Dotan Cohen 2012-11-03 08:54:49 UTC
OpenOffice has an option to use either Logical or Visual cursor control. Kate uses a system that is similar to OOo's Logical setting, which contrary to the name is completely illogical (and seems to only still exist as an historical vestige in OO as the issue is resolved with Visual cursor control).

This Kate bug can be solved by changing Kate's cursor control to use the same Visual cursor control as OO does.

The OO option can be found in any OO or LibreOffice application in this menu: Tools -> Options -> Language Settings -> Complex Text Layout

Thanks!
Comment 11 Diego Iastrubni 2012-11-05 07:08:17 UTC
The problems are deep inside KateViewInternal:

KateViewInternal::left should be called KateViewInternal::nextChar. 
Action move_cusor_left should be called move_cusor_next_char.

The next thing to understand, is that on RTL blocks, moving to the left means 
	moveChar( KateViewInternal::nextChar, sel );
and on LTR blocks it means:
	moveChar( KateViewInternal::prevChar, sel );

The first hack, would check for the directionality of the current block:

void KateViewInternal::cursorLeft(  bool sel )
{
  if ( ! m_view->wrapCursor() && m_cursor.column() == 0 )
    return;

  moveChar( !isBlockRTL(m_cursor) ? 
	KateViewInternal::prevChar: 
	KateViewInternal::nextChar, sel 
   );
}

This is a nice hack, but will will break on documents with mixed blocks (text 
with arabic/hebrew and english), when you press "right arrow" you will get 
stuck between those two parahraphs. (on english it means next char, and when 
yo get into the RTL paragraph it means prev). This happens currently in KMail 
(where I did this hack a few years ago), and I see this also in the Chromium 
rich text editor. The plain text editor works in visual mode... which is not 
something I want to implement in Kate.

In theory, in keyboard repeat events you should remember where the key has 
been pressed, use that to choose prevChar/nextChar, this will fix the problem 
I described above. I will look into Qt's code and see how it is implemented 
there (it seems to work there).

It would be great, if we hardcode those "actions", and arrows (control+shift) 
will behave as needed. And also provide "extra" actions, which are what are 
exported now to users.
Comment 12 Christoph Cullmann 2012-11-05 07:13:17 UTC
Thanks for the investigation, feel free to change the behavior of the Kate internals like you think is fitting. I not really understand the last sentences thought:

It would be great, if we hardcode those "actions", and arrows (control+shift) 
will behave as needed. And also provide "extra" actions, which are what are 
exported now to users.

You mean to fix the normal left,right keys (and shift variants) and export additional actions to allow the user to choose direction?
Comment 13 Diego Iastrubni 2012-11-05 08:03:36 UTC
I mean that the current cursor movement is done by signals emmited by users clicking the right/left arrows. I say: lets had an event filter on the widget, and that those specific keyboard events.

If users was another shortcut - they have those signals.

Regarding the code changes:
I plan to deprecate those old methods, and when calling them print a debug message  and then call moveChar( KateViewInternal::prevChar). 

As that API is public, this needs to be discussed. When are we going into freeze? (we should move this discussion to the ML...)
Comment 14 Christoph Cullmann 2012-11-05 08:43:05 UTC
No API in Kate* is public, feel free to change this ;)
only kate.git/ktexteditor is public.
About the left, right, ... actions, I thought they are all KAction's. I would not use eventFilter but more likely just fix the action functions we have. Users can redefine shortcuts anyway.
Comment 15 Diego Iastrubni 2012-11-05 21:15:19 UTC
I think that doing this by installing an EventFilter instead of [K/Q]actions will be better. It will even help with fixing of issue https://bugs.kde.org/show_bug.cgi?id=187408 (changing the direction of the paragraph by pressing control+shift)
Comment 16 Christoph Cullmann 2012-11-05 21:19:04 UTC
You can do the same with the actions, and you would people that need really different key bindings still allow to rebind them.
Comment 17 Diego Iastrubni 2012-11-05 21:48:20 UTC
1) No you can't ;-)
2) The emmited actions depend on the cursor location. Sometimes right will emit "next char", and sometimes right emits "prev char"
3) Please show me a code that triggers a QAction when you press control+shift (2 modifier, no keyboard). This key combination is used on Windows (and Q3/Qt4) to change the direction of the paragraph. On Mozilla's platforms this is cone by control+shift+x, if I am not mistaking.
Comment 18 Christoph Cullmann 2012-11-05 21:54:07 UTC
1) :)
2) The slot you trigger with your action can just do so, lookup cursor position and do the right thing, you would do that in the event-filter, too
3) Ok ;) that might be true, but that still is no reason to remove the other working actions if you need one to be handled by eventFilter or event handler ;)
Comment 19 Diego Iastrubni 2012-11-19 22:11:41 UTC
Zayed, Dotan,

First fix (basic cursor movement) is in master right now. See:
http://commits.kde.org/kate/af5bf49e5a7b31bb258971b5076af9ab7cda47f0

This is not the end, and I will probably also backport this to the branches.
Comment 20 Dotan Cohen 2012-11-20 13:06:50 UTC
Thanks Diego.
Comment 21 Fahad Al-Saidi 2013-03-06 05:28:28 UTC
I tested in kde 4.10 and it is fixed.
Comment 22 Dominik Haumann 2013-03-06 10:49:36 UTC
Dotan, this can be closed then, right?
Comment 23 Dotan Cohen 2013-03-06 11:08:06 UTC
Zayed, can you confirm that this is fixed on 4.10? I'm still on 4.9 and I won't be building 4.10 in the near future (probably not until my distro ships it to be honest).
Comment 24 Diego Iastrubni 2013-03-08 20:24:05 UTC
Dominik, 

Please don't close it yet. The solution is not good enough for me yet.
Comment 25 Zayed Al-Saidi 2013-04-12 14:43:30 UTC
Today I get a chance to test this bug. The bug is almost fixed. One thing is remained. The ligatures handling is not optimum. For example الله ,  the cursor will handle it as on char, then it will stay on its place while you pressing the arrow key three times. ( الله ligatures represent 4 letters).
Comment 26 Dominik Haumann 2013-08-14 09:59:26 UTC
Can anyone look into the issue mentioned in comment #25? As I understand, this is the last remaining issue here. Is this only kate related, or an issue in all KDE/Qt applications?
Comment 27 Zayed Al-Saidi 2018-11-10 19:06:15 UTC
The issue is exist (what was mentioned in comment #25) using Version 17.12.3.
Comment 28 Justin Zobel 2020-11-02 01:46:42 UTC
(In reply to Zayed Al-Saidi from comment #27)
> The issue is exist (what was mentioned in comment #25) using Version 17.12.3.

Zayed is this bug still persisting?
Comment 29 Zayed Al-Saidi 2020-11-02 20:05:55 UTC
(In reply to Justin Zobel from comment #28)
> (In reply to Zayed Al-Saidi from comment #27)
> > The issue is exist (what was mentioned in comment #25) using Version 17.12.3.
> 
> Zayed is this bug still persisting?

No it isn't. Now ligatures is treated as one char which is fine. I think we can close this bug from user perspective.
Comment 30 Justin Zobel 2020-11-02 22:38:46 UTC
Thanks for your report and feedback Zayed.