still the same in kde 4.1.2

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.

*** Bug 187411 has been marked as a duplicate of this bug. ***

This is upstream bug, please see this:
http://www.qtsoftware.com/developer/task-tracker/index_html?id=254850&method=entry

> 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.

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.

*** Bug 279053 has been marked as a duplicate of this bug. ***

*** Bug 172630 has been marked as a duplicate of this bug. ***

Seems we have serious problems with this, anybody could help out with some patch?

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!

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.

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?

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...)

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.

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)

You can do the same with the actions, and you would people that need really different key bindings still allow to rebind them.

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.

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 ;)

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.

Thanks Diego.

I tested in kde 4.10 and it is fixed.

Dotan, this can be closed then, right?

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).

Dominik, 

Please don't close it yet. The solution is not good enough for me yet.

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).

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?

The issue is exist (what was mentioned in comment #25) using Version 17.12.3.

(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?

(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.

Thanks for your report and feedback Zayed.