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.
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!
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.
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.
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.
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.
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)
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.
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"
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.
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.
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.
I have it from time to time as well...
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.
*** Bug 249649 has been marked as a duplicate of this bug. ***
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
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.
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.
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.
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...
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.
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.
*** Bug 253738 has been marked as a duplicate of this bug. ***
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
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.
I have this problem in Kile 2.0.85 (KDE 4.4.5, Debian Squeeze).
*** Bug 258649 has been marked as a duplicate of this bug. ***
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 :-)
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.
*** Bug 267354 has been marked as a duplicate of this bug. ***
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...
@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?
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.
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
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.
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??
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).
*** Bug 268608 has been marked as a duplicate of this bug. ***
I am also experiencing this bug periodically using Kate 3.4.5 and KDE 4.4.5 from the Debian Sid repositories.
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.
Raymond: In firefox, you can change the text flow with ctrl+shift+x. Is that the behavior you got if you try this?
See also Qt Center, but now answer yet: http://www.qtcentre.org/threads/33062-layoutdirection-switching-during-typing-is-there-a-shortcut-key-when-does-it-happen
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.
(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!
Ok, so maybe it's indeed not a Kate problem... Or maybe it still is...
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).
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.
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.
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!
I think this bug was fixed a long time ago, I've never experienced it again after upgrade to KDE 4.6.
Confirmed. Still occurring. http://www.youtube.com/watch?v=xlOR-4_DBUY
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
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.
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.
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.
I also have not seen this bug since switching to KDE 4.6, but experienced it before.
I've not seen this defect in a long time anymore, we can probably assume it was fixed at some point.
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!
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!