Bug 246162 - text typing direction suddenly changes RTL LTR
Summary: text typing direction suddenly changes RTL LTR
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: VHI major
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords: triaged
: 249649 253738 258649 267354 268608 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-07-29 15:43 UTC by edA-qa mort-ora-y
Modified: 2018-10-27 03:45 UTC (History)
34 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description edA-qa mort-ora-y 2010-07-29 15:43:05 UTC
Version:           unspecified (using KDE 4.4.5) 
OS:                Linux

While writing code in Kate the text direction of entry changes for an unidentifiable reason. This happens about once or twice a week.

That is, I always write in LTR and all my installed languages are LTR but then suddenly Kate will start accepting characters RTL instead. So if I type "hello" I actually get "olleh".

Once this happens there is an "area" of the file which then remains in this RTL configuration. If I move the cursor outside of this area entry is normal, but back in the area the entry is reversed.  There is no visual indication about the entry direction.

I can find no menu item, no keyboard shortcut, or anything else that even references text direction.  There is also no easy way to fix the problem -- usually I end up closing kate and restarting it again.

Reproducible: Sometimes

Steps to Reproduce:
I don't know why it happens, I just know that it happens once or twice a week while coding.


Expected Results:  
Without a specific request from me I'd never expect the typing direction to change. Perhaps if I switched languages I can understand, but the only to keyboard layouts/languages I use are english (USA altgr-intl) and german.
Comment 1 Brian DeRocher 2010-08-04 21:50:55 UTC
YES! I get this too.  I edit PHP.  It's something related to the text encoding.  If i recall correctly, in order to fix it, i once changed it to UTF-16 and then back to UTF-8 and the text direction returns to Left to Right.

Very intermittent!
Comment 2 Milian Wolff 2010-08-05 00:00:53 UTC
You probably hit some shortcut that either triggers the RTL/LTR switch in Qt (I read the sources and could only find something related to ctrl + shift on either right or left side but could not reproduce it myself...). Or maybe you insert the RTL/LTR unicode character somehow?

Anyways, I doubt there is anything we can do in Kate to prevent this. If either of you actually finds out what shortcut you hit to trigger it, please let us know. Then we could try to eat that shortcut and ask the user whether he really wants to change the direction.
Comment 3 edA-qa mort-ora-y 2010-08-05 07:35:16 UTC
It is possible I hit a shortcut key, but I've checked all shortcut key listings and none of them seem to include a direction shift shortcut.

Additionally, my keyboard layouts are US (us-intl) and DE, there are no characters they can insert which have a different directionality.

If this is not an issue with Kate, then please indicate with which component I should file the issue.
Comment 4 Milian Wolff 2010-08-05 12:35:19 UTC
You would probably have to go directly to Nokia (i.e. the maintainers of Qt) and ask them for help.

Regarding Shortcut: It's not a KDE action, hence it won't show up in the shortcut key listing. Instead it's (probably) a hardcoded Qt shortcut, similar to things like "Tab key focuses next widget".

Regarding keyboard layout: Under linux you can insert special characters with a combination of "Alt Gr" + [Shift] + something. It could be that there is /some/ combination that would insert a dir-shift-unicode-character. But again: This is also just a guess.

Please, if you find out (maybe via Nokia) what the trigger is for this issue - notify us and maybe we can find a workaround.
Comment 5 edA-qa mort-ora-y 2010-08-05 13:41:19 UTC
I'll try to work my way through the various QT forums and then their bug system to see if I can find something.

It would be helpful if you could say what underling widget the main editor is using. Does it derive from a standard, or is it just a custom QWidget?

I'm thinking it isn't a cahracter that shifts direction, since according to this:
http://dry.sailingissues.com/us-international-keyboard-layout.html
There are no RTL characters I can type using the us altgr-intl layout.
Comment 6 K.J. Petrie 2010-08-12 19:09:40 UTC
I have just experienced this for the first time after the latest upgrade in PCLinuxOS yesterday. I have never had anything of this nature happen before but today it has happened twice in the editing of one document. The document, pasted from a .docx file, contains numerous non ISO-8851-1 characters and therefore cannot be saved until editing is complete.

Both times it happened I could find no option in the Kwrite configuration to switch typing direction, but mysteriously was able to change it back by dragging the scrollbox, clicking on a much earlier part of the document and typing there then deleting. I was then able to return to the place I was editing and the direction of typing had now changed.

Please re-open this bug. There is definitely something needing investigating.

In case it helps, here is the full list of packages involved in yesterday's upgrade:

Commit Log for Wed Aug 11 11:00:12 2010


Removed the following packages:
libpoppler-qt4-5

Upgraded the following packages:
ImageMagick (6.5.8.10-2pclos2010) to 6.6.3.4-1pclos2010
akonadi (1.3.0-2pclos2010) to 1.3.90-1pclos2010
cups (1.4.4-3pclos2010) to 1.4.4-5pclos2010
cups-common (1.4.4-3pclos2010) to 1.4.4-5pclos2010
digikam (1.3.0-2pclos2010) to 1.3.0-5pclos2010
dvdauthor (0.6.14-3pclos2010) to 0.6.14-4pclos2010
gdk-pixbuf-loaders (0.22.0-16pclos2010) to 0.22.0-19pclos2010
getopenoffice (1.8-1pclos2010) to 1.8-2pclos2010
ghostscript (8.64-70pclos2010) to 8.64-71pclos2010
ghostscript-X (8.64-70pclos2010) to 8.64-71pclos2010
ghostscript-common (8.64-70pclos2010) to 8.64-71pclos2010
ghostscript-module-X (8.64-70pclos2010) to 8.64-71pclos2010
gimp (2.6.10-1pclos2010) to 2.6.10-3pclos2010
inkscape (0.47-3pclos2010) to 0.47-5pclos2010
kdebase4-runtime (4.4.5-1pclos2010) to 4.4.5-4pclos2010
kdegraphics4 (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-core (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-gwenview (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-kamera (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-kcolorchooser (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-kgamma (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-kolourpaint (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-kruler (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-ksnapshot (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdegraphics4-okular (4.4.5-3pclos2010) to 4.4.5-6pclos2010
kdelibs4 (4.4.5-1pclos2010) to 4.4.5-4pclos2010
kdenetwork4 (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-core (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-filesharing (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-kdnssd (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-kget (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-kopete (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-kopete-latex (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-kppp (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-kppp-provider (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdenetwork4-krdc-krfb (4.4.5-2pclos2010) to 4.4.5-4pclos2010
kdepimlibs4 (4.4.5-1pclos2010) to 4.4.5-2pclos2010
kffmpegthumbnailer (1.1.0-1pclos2010) to 1.1.0-3pclos2010
kipi-plugins (1.3.0-2pclos2010) to 1.3.0-5pclos2010
lcms (1.19-2pclos2010) to 1.19-4pclos2010
lensfun (0.2.3-1pclos2009) to 0.2.5-1pclos2010
libcdt4 (2.24.0-1pclos2010) to 2.24.0-3pclos2010
libcups2 (1.4.4-3pclos2010) to 1.4.4-5pclos2010
libcv2 (2.0.0-3pclos2010) to 2.0.0-5pclos2010
libcvaux2 (2.0.0-3pclos2010) to 2.0.0-5pclos2010
libcxcore2 (2.0.0-3pclos2010) to 2.0.0-5pclos2010
libdirectfb1.4_0 (1.4.2-5pclos2010) to 1.4.2-7pclos2010
libdjvulibre21 (3.5.21-1pclos2010) to 3.5.22-2pclos2010
libffmpegthumbnailer4 (2.0.2-1pclos2010) to 2.0.2-3pclos2010
libgd2 (2.0.35-3pclos2010) to 2.0.35-5pclos2010
libgdk-pixbuf2 (0.22.0-16pclos2010) to 0.22.0-19pclos2010
libgimp2.0_0 (2.6.10-1pclos2010) to 2.6.10-3pclos2010
libgphoto-common (2.4.9-1pclos2010) to 2.4.9-3pclos2010
libgphoto2 (2.4.9-1pclos2010) to 2.4.9-3pclos2010
libgraph4 (2.24.0-1pclos2010) to 2.24.0-3pclos2010
libgs8 (8.64-70pclos2010) to 8.64-71pclos2010
libgvc5 (2.24.0-1pclos2010) to 2.24.0-3pclos2010
libhighgui2 (2.0.0-3pclos2010) to 2.0.0-5pclos2010
libidn11 (1.14-1pclos2009) to 1.19-2pclos2010
libijs1 (0.36-70pclos2010) to 0.36-71pclos2010
libimlib2_1 (1.4.3-1pclos2010) to 1.4.4-3pclos2010
libimlib2_1-filters (1.4.3-1pclos2010) to 1.4.4-3pclos2010
libimlib2_1-loaders (1.4.3-1pclos2010) to 1.4.4-3pclos2010
liblcms1 (1.19-2pclos2010) to 1.19-4pclos2010
liblensfun0 (0.2.3-1pclos2009) to 0.2.5-1pclos2010
liblqr0 (0.4.1-2pclos2010) to 0.4.1-3pclos2010
libmjpegtools1.9 (1.9.0-5pclos2010) to 1.9.0-7pclos2010
libml2 (2.0.0-3pclos2010) to 2.0.0-5pclos2010
libmng1 (1.0.10-1pclos2010) to 1.0.10-3pclos2010
libopenraw1 (0.0.8-1pclos2010) to 0.0.8-3pclos2010
libpathplan4 (2.24.0-1pclos2010) to 2.24.0-3pclos2010
libphonon4 (4.4.1-2pclos2010) to 4.4.2-1pclos2010
libphononexperimental4 (4.4.1-2pclos2010) to 4.4.2-1pclos2010
librsvg2_2 (2.26.2-1pclos2010) to 2.26.2-2pclos2010
libsoprano4 (2.4.2-1pclos2010) to 2.4.64-1pclos2010
libsopranoclient1 (2.4.2-1pclos2010) to 2.4.64-1pclos2010
libsopranoindex1 (2.4.2-1pclos2010) to 2.4.64-1pclos2010
libsopranoserver1 (2.4.2-1pclos2010) to 2.4.64-1pclos2010
libspectre1 (0.2.3-2pclos2010) to 0.2.3-4pclos2010
libtiff3 (3.9.4-1pclos2010) to 3.9.4-4pclos2010
libwebkitgtk1.0_2 (1.3.1-2pclos2010) to 1.3.1-3pclos2010
libwmf (0.2.8.4-8pclos2007) to 0.2.8.4-11pclos2010
libwmf0.2_7 (0.2.8.4-8pclos2007) to 0.2.8.4-11pclos2010
libwrap0 (7.6-36pclos2007) to 7.6-37pclos2010
libxine1 (1.1.17-6pclos2010) to 1.1.19-3pclos2010
libxulrunner1.9.2.8 (1.9.2.8-2pclos2010) to 1.9.2.8-4pclos2010
mjpegtools (1.9.0-5pclos2010) to 1.9.0-7pclos2010
phonon-xine (4.4.1-2pclos2010) to 4.4.2-1pclos2010
poppler (0.12.2-2pclos2010) to 0.14.1-2pclos2010
seamonkey (2.0.6-1pclos2010) to 2.0.6-4pclos2010
soprano (2.4.2-1pclos2010) to 2.4.64-1pclos2010
soprano-plugin-common (2.4.2-1pclos2010) to 2.4.64-1pclos2010
soprano-plugin-virtuoso (2.4.2-1pclos2010) to 2.4.64-1pclos2010
strigi (0.7.1-2pclos2010) to 0.7.2-1pclos2010
tcp_wrappers (7.6-36pclos2007) to 7.6-37pclos2010
virtuoso-opensource (6.1.0-1pclos2010) to 6.1.1-3pclos2010
webkit (1.3.1-2pclos2010) to 1.3.1-3pclos2010
webkit1.0 (1.3.1-2pclos2010) to 1.3.1-3pclos2010
webkit1.0-webinspector (1.3.1-2pclos2010) to 1.3.1-3pclos2010
whois (4.7.13-2pclos2007) to 5.0.6-1pclos2010
xine-plugins (1.1.17-6pclos2010) to 1.1.19-3pclos2010
xine-pulse (1.1.17-6pclos2010) to 1.1.19-3pclos2010
xulrunner (1.9.2.8-2pclos2010) to 1.9.2.8-4pclos2010

Installed the following packages:
libmagick4 (6.6.3.4-1pclos2010)
libpoppler-glib5 (0.14.1-2pclos2010)
libpoppler-qt4-3 (0.14.1-2pclos2010)
libpoppler6 (0.14.1-2pclos2010)
Comment 7 david 2010-08-23 09:27:56 UTC
I have found the same thing happening in a program I am developing in PyQt, running in KDE. The widget concerned in my case is a customised QPlainTextEdit. The customisation just adds a couple of simple functions to read and set the text, nothing to do with text direction or unicode characters. Since I couldn't find any way to change the text direction back (including QWidget.setLayoutDirection()), I tried deleting the widget in QDesigner and reinserting a new one. The text is still backwards.  This seems to indicate that KDE (or Qt) tracks which widgets in which application are set RTL, and sets the diriection accordingly on startup.
Comment 8 david 2010-08-23 09:40:30 UTC
On closer inspection, I don't think that it is a RTL issue. It appears that the cursor is being moved to the start of the line after every character is typed, so "hello" comes out as "olleh". Pasting the text "hello " and typing "world" comes out as "dlrohello w"
Comment 9 FiNeX 2010-08-23 12:20:32 UTC
I agree with david: the editor doesn't switch to RTL and I'm sure it is not triggered by a shortcut because it happens me a couple of times each day and I'm 100% sure I've not pressed any shortcut combo. Moreover I don't use special chars while typing code.
Comment 10 Jon Nelson 2010-08-25 23:48:26 UTC
I hit this but with some frequency, but I can't be sure I've hit it since upgrading to 4.5.0.

I'll keep an eye out for it though.
However, why is it closed?
The last comment is only a few days old.
Comment 11 edA-qa mort-ora-y 2010-09-18 15:39:38 UTC
Other people report this issue. I have not been able to track down any source in the QT controls. And I've not seen this behavior in other applications that use QT. There is no reason to not suspect this is a defect in katepart/kate itself.

I've reopened it for these reasons.
Comment 12 Dominik Haumann 2010-09-20 00:11:15 UTC
I have it from time to time as well...
Comment 13 Thomas Fjellstrom 2010-09-20 00:24:03 UTC
I'm not convinced this is a kate specific problem. As one person mentioned he was using a plain old Qt control. And I've heard people having this problem with other programs, and in windows. It just seems to happen more often with kate.

That said, I haven't seen it in a little while. Possibly since I started using KDE 4.5, or Qt 4.7. Not entirely sure when it last happened.
Comment 14 Milian Wolff 2010-09-20 14:23:18 UTC
*** Bug 249649 has been marked as a duplicate of this bug. ***
Comment 15 Edwin Boersma 2010-10-02 20:05:37 UTC
This weird behaviour certainly came with my latest upgrade to opensuse 11.3. It happens regularly, but not too often (luckily).

The only workaround I have found is to save and close the document and open it again, which indicates to me that it's not an RTL-character being inserted.

It also seems that the problem only affects the current line I'm editing. Do others have the same experience?

Regards,
Edwin
Comment 16 Nicolas Bigaouette 2010-10-02 23:02:30 UTC
For me, when that happens, it's everywhere in the document. The only workaround is (saving and) refreshing the document (F5). Re-opening probably does the same.
Comment 17 edA-qa mort-ora-y 2010-10-03 07:30:33 UTC
I've tracked some of my direction shifts and they appear to be related to a block of code. Either several columns on one-line, or several lines at a time. Outside that region the typing direction is correct.

Curiously, you can cut-and-paste the section and retain the incorrect typing direction.
Comment 18 Frank 2010-10-06 14:40:08 UTC
I am also experiencing this bug in OpenSuse 11.3: Kile Version 2.0.85

This suggests a problem with the kpart system 

Unfortunately, I cannot give exact steps to reproduce at present.
Comment 19 Raymond Wan 2010-10-06 17:19:47 UTC
I know this doesn't help, but for what it's worth, I get it every few days.  But just to add to the list, I'm running:

Qt: 4.6.3
KDE Development Platform: 4.4.5 (KDE 4.4.5)
Kate: 3.4.5

On Debian 6.0 (testing), which hasn't be listed by anyone else yet...  I will try to remember what I did to trigger it, but it usually happens while hitting normal keys and not some CTRL/ALT combination.  Also, I wouldn't call it changing the text direction to "RTL" for one minor reason.  When we type LTR, the cursor advances to the right with each character.  When this bug is triggered, the cursor stays put and characters get added RTL.  I suppose if it was truly RTL, the cursor should move to the left...  (However, credit to the original reporter of this bug...RTL/LTR is a good way of describing it quickly.)

I will see if I notice any other patterns that can help trigger this bug...
Comment 20 Dominik Haumann 2010-10-07 00:22:56 UTC
what would help:
install the -devel packages of kate and katepart (kdelibs and kdesdk). If the bug appears, attach with gdb and search for the reason.
Instead of using development packages, you can also build kate yourself (best way to hunt this down): http://kate-editor.org/get-it/

Further, a way to reproduce is needed. This bug indeed exists. I'm also experiencing this from time to time.
Comment 21 Brian DeRocher 2010-10-07 03:12:27 UTC
I'd like to echo what Raymond says in comment #19.  This occurs for me too.  The cursor keeps its position and the characters are pushed to the right.  I also agree that it does not happen with a special key combination.  For me it happened when i his enter tab tab very quickly.  I could not reproduce it.
Comment 22 Dominik Haumann 2010-10-10 21:18:34 UTC
*** Bug 253738 has been marked as a duplicate of this bug. ***
Comment 23 didier fabert 2010-10-28 10:07:06 UTC
bug is present here too, but with Kate and KDevelop ....
So Kate and KWrite are probably clean and problem is probably in the dependencies (KPart, QT .... ) 

Debian SID
KDE 4.4.5
KDevelop 4.0.1 (using KDevPlatform 1.0.1)
Kate 3.4.5
Qt 4.6.3
Comment 24 triffid.hunter 2010-11-10 05:24:24 UTC
this happens to me in kate with frustrating frequency. sometimes, going to a different part of the document and typing some text in, then going back to the affected region fixes it, sometimes it doesn't. Sometimes I have to try several different areas until I find one that resets the behaviour.

When the behaviour occurs, saving the file and viewing in another editor doesn't show any strange characters. I'm certain I'm not hitting any weird shortcuts, and my alt-gr is remapped to regular alt. Kate is the only program on my system in which I have noticed this occurring regularly.
Comment 25 Adriano Vilela 2010-11-25 00:41:33 UTC
I have this problem in Kile 2.0.85 (KDE 4.4.5, Debian Squeeze).
Comment 26 Milian Wolff 2010-12-03 12:17:19 UTC
*** Bug 258649 has been marked as a duplicate of this bug. ***
Comment 27 Arne Henningsen 2011-01-20 16:13:02 UTC
I experience the same problem from time to time in kile 2.0.85, KDE 4.4.5, Ubuntu 10.04. Really annoying!

@Nicolas: Thanks a lot for sharing your workaround (refresh, F5) with us! This is really helpful :-)
Comment 28 Darlene Adler 2011-02-14 21:55:46 UTC
I ran into this problem fro the first time while editing a plain .txt file in Kate on KDE Gentoo.  I'm not sure what that has to do with anything, but I read a comment about this happening after a quick double-tab, so I put the cursor back on the offending line and did a quick double tab.  I started to type and it was back to normal.
Comment 29 Erlend Hamberg 2011-03-01 07:07:55 UTC
*** Bug 267354 has been marked as a duplicate of this bug. ***
Comment 30 Dominik Haumann 2011-03-01 08:41:59 UTC
This issue is around for quite time now. As we do not have a way to reproduce, it's hard to get a fix. Hence, what I would like all followers here to do is this:
- install the -debug packages of Kate
- when the bug appears, attach with gdb
- set a breakpoint in some kate typing function (insertChar or similar)
- try to step through the code to find out what happens...
I don't really see another way...
Comment 31 SasQ 2011-03-01 16:43:19 UTC
@Dominik: "set a breakpoint in some kate typing function (insertChar or similar)"
Can you elaborate on this? I've tried to attach to the running Kate and it attached correctly, but when I'm trying to set a breakpoint it says that insertChar function doesn't exist.
Is it a global function or in some object?
What command could I use to set a breakpoint on that function in GDB?
Are there other functions I could attach if this one won't be enough?
Comment 32 Frank 2011-03-01 18:44:48 UTC
I recently also experienced this bug when typing a email in evolution under KDE (OpenSuse 11.3, Evolution 2.30.1.2). No idea how I triggered it.  This could indicate it is a larger problem than just kpart elements, but somehow it gets triggered more often in those editors.
Comment 33 Dominik Haumann 2011-03-01 21:43:59 UTC
To be more precise: the classes in detail are:
- KateViewInternal::keyPressEvent
- KateDocument::typeChars

Functions that might be related:
- KateViewInternal::inputMethodQuery
- KateViewInternal::inputMethodEvent

You can set a breakpoint with e.g.: break KateViewInternal::keyPressEvent
Comment 34 Thomas Guymer 2011-03-05 15:57:30 UTC
I have just experienced this bug/feature for the first time today.

I am using openSUSE 11.3 with KDE4.4.4 and Kate 3.4.4.
Comment 35 Andreas Pakulat 2011-03-10 22:59:11 UTC
Milian just pointed to this in irc and as I was kinda interested as I know I was bitten by it quite a bit during KDev3 times. I think the interesting code from qt is in qkeymapper_x11.cpp, translateKeyEventInternal. That function suggests that just Ctrl+Shift (either left or right) triggers a direction change (along with qlineedit.cpp's keyPressEvent, search for setLayoutDirection). Unfortunately I don't quite understand that Qt code and I have no easy way of building a Qt myself these days to find out if/when/how this can be triggered. FWIW just typing Ctrl+Shift does not do anything here on my machine, but maybe there's some X11 setup needed as well??
Comment 36 Andreas Pakulat 2011-03-10 23:02:40 UTC
PS: QTextControl also uses that, so if katepart uses QTextControl directly or indirectly for its text-formatting than that might be how its coming to katepart (as QWidget does not seem to have code for Qt::Key_Direction_L).
Comment 37 Tomas Trnka 2011-03-16 10:38:26 UTC
*** Bug 268608 has been marked as a duplicate of this bug. ***
Comment 38 flipmodeplaya 2011-03-16 16:26:31 UTC
I am also experiencing this bug periodically using Kate 3.4.5 and KDE 4.4.5 from the Debian Sid repositories.
Comment 39 Raymond Wan 2011-06-20 11:33:51 UTC
I'm not sure if anyone else experienced this yet, but after having this problem for over half a year in Kate, Kdevelop, etc., I encountered it for the first time in Iceweasel (Debian's rebranded Firefox) while in a Google chat window.  While typing, the text suddenly reversed exactly as I had experienced in Kate, etc.

Does this mean the source of the problem is "higher up"?  I'm using Gnome as my window manager, though.  However, I don't use the Gnome equivalents to Kate, Kdevelop, etc. so I wouldn't know if those tools have the same problem.

One similarity between the two problems is that I can't repeat it and nothing I was doing at the time was particularly special...

Not sure if this helps and hope it doesn't confuse things.  It may be an entirely different problem with the same symptom.
Comment 40 Dominik Haumann 2011-06-20 22:10:41 UTC
Raymond: In firefox, you can change the text flow with ctrl+shift+x. Is that the behavior you got if you try this?
Comment 42 Beco 2011-06-20 22:35:45 UTC
About comment #37, or the duplicate bug #268608, the description is:

Some times, I don't figured out when yet, kate starts writing in the inverse
direction, and starts overwriting the word with 2 chars length. For example, if
you type the word "case", it would appear as "ec", the cursor blinks at "e",
and keeps there overwriting.

Strange... I'm using UBUNTU 10.04, and Kate is 3.4.5. The application version
was not available in the field above to specify.

Actual Results:  
Can't write anymore. It starts writing inversed for 2 chars, and then
overwriting at the same place. Need to save, close application, and restart to
keep working.

Thanks.
Beco

PS. I have only LTR languages installed. No shortcuts typed.
Comment 43 Raymond Wan 2011-06-21 11:19:02 UTC
(In reply to comment #40)
> Raymond: In firefox, you can change the text flow with ctrl+shift+x. Is that
> the behavior you got if you try this?

Thank you for bringing this up -- I didn't realize there was such a hotkey in Firefox/Iceweasel.  I can't reproduce the problem I got yesterday but the behavior still seems different.

So, I'm typing in English and as I type each character, my cursor is moving to the right.  When I hit CTRL+Shift+x, the cursor jumps to the right side of the text box and as characters appear, they move to the left with the cursor still on the far right.

However, for the problem I got yesterday, the cursor is in the middle of the text window (at the point where it changed behavior...) and stays there.  Then, text moves to the right.

So, in the first two cases (my default and with CTRL+Shift+x), if I type the word "hello", "hello" appears.  With the problem yesterday, "olleh" appears with the cursor situation to the left of the "o".  This is essentially the problem I am having with kate, kdevelop, etc.

I guess I could have hit "F5" to reload the page, but I just closed the chat window.  I'm fairly certain that I didn't hit CTRL+Shift+x by accident -- the change happened mid-sentence.

If this happens to me again, I'll double check by hitting CTRL+Shift+x to see what happens.  Thanks!
Comment 44 Dominik Haumann 2011-06-21 18:52:51 UTC
Ok, so maybe it's indeed not a Kate problem... Or maybe it still is...
Comment 45 Lars Winterfeld 2011-06-21 22:13:20 UTC
I would guess that 'c' 'a' 's' 'e' -> "ec" is a different bug.

I also think that all of this is not related to a shortcut, because:
(a) none of us remembers pushing random buttons on the keyboard and
(b) when I scroll up and type there, it is still normal (LTR), the inverse mode (RTL) seems to be active in only a part of the document. (this was also described in comment #6)

btw, I experienced this bug once in kile, but *until now* never in TexMaker (which is also a Qt program, but does not use the kdelibs).
Comment 46 joachim.protze 2011-08-18 12:49:45 UTC
I found this behaviour in kile and kate, with Ubuntu 10.04 and 11.04.

I think, that i always triggered this behaviour by marking text to overwrite it. I usually navigate with cursor + ctrl-key trough the text. I'm not sure, but i think i always marked the word from right to left and than began to type the new word - so the combination was Ctrl+Shift+left.
This observation matches with Andreas Pakulat's comment.
As triffid.hunter@gmail.com wrote, finding a region with RTL and returning to the bugged region may fix the behaviour.
Comment 47 Daniel 2012-01-15 16:52:01 UTC
I also experience this bug repeatedly in Kile (Ubuntu 10.04). It really seems impossible to reproduce it. The direction change often seems to occur after I have cut, pasted, commented out or uncommented larger blocks. Yet I just happened to experience the problem after commenting out only a few words at the end of a line (with % via Shift+5 on my keyboard layout). Sometimes, cutting and redoing does the trick, sometimes only cutting and pasting helps. It's always restricted to an "infected" area of the document.

I just tried Ctrl+Shift+x in my Firefox search bar and it had a similar effect as in Kile. Then I tried it out in Kile and indeed it messed up the direction. Having fixed the direction by cut and paste, I could not reproduce it. This is damn odd. I'd start believing I'm insane if there hadn't been so many comments.
Comment 48 Josh Lehan 2012-01-27 00:29:17 UTC
Yes!  I have this bug happen to me, too.  It's very frustrating when it happens.

I'm running KDevelop 4.0.0 on KDE 4.4.4.

It seems to happen most often when cutting and pasting text in the editor.  Sometimes, the lines containing the pasted text will be "tainted" and the cursor will have the buggy RTL behavior described in this bug.

Going to another area of the file, and typing text in there, and then cutting and pasting that text, seems to be a valid workaround.  The pasted text appears in the correct order.  However, any typing the user tries to do in that area will still be backwards.

Closing and reopening the file is also a valid workaround.

I'm using US English settings, my keyboard contains no RTL characters, nor any way to voluntarily enter RTL mode when inserting text by typing it with the keyboard.  A strange bug, to say the least!
Comment 49 Lukáš Turek 2012-01-27 01:04:11 UTC
I think this bug was fixed a long time ago, I've never experienced it again after upgrade to KDE 4.6.
Comment 50 Beco 2012-02-01 16:12:51 UTC
Confirmed. Still occurring.

http://www.youtube.com/watch?v=xlOR-4_DBUY
Comment 51 Beco 2012-04-06 15:43:34 UTC
Important information:

This bug occurred also when I was using kile (latex frontend) today. So, whatever it is, is not just kate related, but a bit deeper.
Using debian stable updated:

$ uname -a
Linux gaviao 2.6.32-5-amd64 #1 SMP Sat Mar 31 04:00:05 UTC 2012 x86_64 GNU/Linux


$ lsb_release -a
LSB Version:    core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:qt4-3.1-amd64:qt4-3.1-noarch
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.4 (squeeze)
Release:        6.0.4
Codename:       squeeze


$ dpkg -p kile
Package: kile
Priority: optional
Section: tex
Installed-Size: 11168
Maintainer: Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
Architecture: amd64
Version: 1:2.1.0~svn1112278beta4-2
Replaces: ktexmaker2 (<< 1.8)
Depends: kdebase-runtime, libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libkdecore5 (>= 4:4.4.4), libkdeui5 (>= 4:4.4.4), libkfile4 (>= 4:4.4.4), libkhtml5 (>= 4:4.4.4), libkio5 (>= 4:4.4.4), libkjsapi4 (>= 4:4.4.4), libkparts4 (>= 4:4.4.4), libkrosscore4 (>= 4:4.4.4), libktexteditor4 (>= 4:4.4.4), libqt4-dbus (>= 4:4.5.3), libqt4-network (>= 4:4.5.3), libqt4-script (>= 4:4.5.3), libqt4-svg (>= 4:4.5.3), libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.6.1), libqtgui4 (>= 4:4.5.3), libstdc++6 (>= 4.1.1), konsole, texlive-base-bin, texlive-latex-base
Recommends: asymptote, context, dblatex, dvipdfmx, dvipng, ghostscript, imagemagick, kbibtex | pybliographer | gbib | jabref, konqueror | iceweasel, latex2html, lilypond, okular | evince | gv, psutils, tex4ht, texlive-metapost, texlive-xetex, zip
Suggests: kile-doc, kile-i18n, texlive-doc-base, aspell | ispell | hspell
Conflicts: ktexmaker2 (<< 1.8)
Size: 1925178
Description: KDE Integrated LaTeX Environment
 Kile is a user-friendly LaTeX source editor and TeX shell for KDE.
 .
 The source editor is a multi-document editor designed for .tex and .bib
 files.  Menus, wizards and auto-completion are provided to assist with
 tag insertion and code generation.  A structural view of the document
 assists with navigation within source files.
 .
 The TeX shell integrates the various tools required for TeX processing.
 It assists with LaTeX compilation, DVI and postscript document viewing,
 generation of bibliographies and indices and other common tasks.
 .
 Kile can support large projects consisting of several smaller files.
Homepage: http://kile.sourceforge.net



$ dpkg -p kate
Package: kate
Priority: optional
Section: editors
Installed-Size: 3848
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Architecture: amd64
Source: kdesdk
Version: 4:4.4.5-1
Depends: kdebase-runtime, libc6 (>= 2.3), libkde3support4 (>= 4:4.3.4), libkdecore5 (>= 4:4.4.4-2~), libkdeui5 (>= 4:4.3.4), libkfile4 (>= 4:4.3.4), libkio5 (>= 4:4.3.4), libknewstuff2-4 (>= 4:4.3.4), libknewstuff3-4 (>= 4:4.4.0), libkparts4 (>= 4:4.3.4), libktexteditor4 (>= 4:4.3.4), libplasma3 (>= 4:4.4.4-2~), libqt4-dbus (>= 4:4.5.3), libqt4-qt3support (>= 4:4.5.3), libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.6.1), libqtgui4 (>= 4:4.6.1), libstdc++6 (>= 4.4.0)
Suggests: aspell | ispell | hspell, khelpcenter4, konsole
Size: 1281932
Description: K Advanced Text Editor
 Kate is a powerful text editor that can open multiple files simultaneously.
 .
 With a built-in terminal, syntax highlighting, and tabbed sidebar, it performs
 as a lightweight but capable development environment.  Kate's many tools,
 plugins, and scripts make it highly customizable.
 .
 Kate's features include:
 .
  * Multiple saved sessions, each with numerous files
  * Scriptable syntax highlighting, indentation, and code-folding
  * Configurable templates and text snippets
  * Symbol viewers for C, C++, and Python
  * XML completion and validation
 .
 This package is part of the KDE Software Development Kit module.
Homepage: http://www.kde.org


Please, forgive me if I forgot any useful information.

Thanks,
Beco
Comment 52 j__n 2012-04-20 07:52:03 UTC
I'm not sure if this helps, but in addition to getting stuck in this mode, I also notice it happening during auto-saves.  More specifically, my files live on a network file system and sometimes saving is slow.  If I type while it's saving, they appear right-to-left.
Comment 53 Christoph Cullmann 2012-10-27 17:54:52 UTC
I think this really was fixed, latest reports are still for KDE 4.4.x.
If not, we need a test to really reproduce it, to fix it.
Comment 54 Nicolas Bigaouette 2012-10-27 19:43:46 UTC
It's been a while since I've seen the problem on ArchLinux. On another Gentoo machine (with always the latest KDE) I've never seen it in a year and a half.
Comment 55 Marcel Martin 2012-10-27 19:49:34 UTC
I also have not seen this bug since switching to KDE 4.6, but experienced it before.
Comment 56 edA-qa mort-ora-y 2016-06-12 12:38:44 UTC
I've not seen this defect in a long time anymore, we can probably assume it was fixed at some point.
Comment 57 Andrew Crouthamel 2018-09-26 22:24:05 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 58 Andrew Crouthamel 2018-10-27 03:45:19 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!