165397 2008-06-30 10:44:01 +0000 [BiDi/Unicode] Right/left arrows do not work in RTL mode 2020-11-02 22:38:46 +0000 1 1 2 Applications kate kwrite unspecified Ubuntu Linux RESOLVED FIXED rtl NOR normal --- 1 zayed.alsaidi kwrite-bugs-null christoph ebrahim elcuco Fahad.alsaidi justin.zobel kde-2011.08 30 oldest_to_newest 618229 0 zayed.alsaidi 2008-06-30 10:44:01 +0000 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 652501 1 zayed.alsaidi 2008-10-10 12:45:08 +0000 still the same in kde 4.1.2 652676 2 elcuco 2008-10-11 01:44:07 +0000 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. 744634 3 kde-2011.08 2009-04-18 20:28:47 +0000 *** Bug 187411 has been marked as a duplicate of this bug. *** 771773 4 zayed.alsaidi 2009-06-08 07:06:30 +0000 This is upstream bug, please see this: http://www.qtsoftware.com/developer/task-tracker/index_html?id=254850&method=entry 772064 5 kde-2011.08 2009-06-08 21:09:24 +0000 > 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. 1183655 6 zayed.alsaidi 2011-11-10 15:19:07 +0000 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. 1311471 7 christoph 2012-11-01 15:23:41 +0000 *** Bug 279053 has been marked as a duplicate of this bug. *** 1311875 8 christoph 2012-11-02 22:46:25 +0000 *** Bug 172630 has been marked as a duplicate of this bug. *** 1311876 9 christoph 2012-11-02 22:46:42 +0000 Seems we have serious problems with this, anybody could help out with some patch? 1311953 10 kde-2011.08 2012-11-03 08:54:49 +0000 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! 1312559 11 elcuco 2012-11-05 07:08:17 +0000 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. 1312560 12 christoph 2012-11-05 07:13:17 +0000 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? 1312572 13 elcuco 2012-11-05 08:03:36 +0000 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...) 1312584 14 christoph 2012-11-05 08:43:05 +0000 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. 1312829 15 elcuco 2012-11-05 21:15:19 +0000 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) 1312830 16 christoph 2012-11-05 21:19:04 +0000 You can do the same with the actions, and you would people that need really different key bindings still allow to rebind them. 1312833 17 elcuco 2012-11-05 21:48:20 +0000 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. 1312834 18 christoph 2012-11-05 21:54:07 +0000 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 ;) 1316797 19 elcuco 2012-11-19 22:11:41 +0000 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. 1316965 20 kde-2011.08 2012-11-20 13:06:50 +0000 Thanks Diego. 1348181 21 Fahad.alsaidi 2013-03-06 05:28:28 +0000 I tested in kde 4.10 and it is fixed. 1348226 22 dhaumann 2013-03-06 10:49:36 +0000 Dotan, this can be closed then, right? 1348230 23 kde-2011.08 2013-03-06 11:08:06 +0000 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). 1349097 24 elcuco 2013-03-08 20:24:05 +0000 Dominik, Please don't close it yet. The solution is not good enough for me yet. 1359963 25 zayed.alsaidi 2013-04-12 14:43:30 +0000 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). 1389651 26 dhaumann 2013-08-14 09:59:26 +0000 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? 1811673 27 zayed.alsaidi 2018-11-10 19:06:15 +0000 The issue is exist (what was mentioned in comment #25) using Version 17.12.3. 1970886 28 justin.zobel 2020-11-02 01:46:42 +0000 (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? 1971134 29 zayed.alsaidi 2020-11-02 20:05:55 +0000 (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. 1971184 30 justin.zobel 2020-11-02 22:38:46 +0000 Thanks for your report and feedback Zayed.