Version: 3.1 (using KDE 4.1.0KDE 1.2) Installed from: Ubuntu Packages0 OS: Linux This affects both Kwrite and Kate, but not other editors such as Gedit, so I presume the problem is in the Kate Part backend. If I'm in the editor and I leave a certain amount of text (a word, a paragraph, the whole file...) selected, and then change to another application, when I come back to the editor, the selected text will be deleted. That obviously shouldn't happen.
Is it possible that you start typing while the selection still exists, even if it isn't on screen? That would cause the selected text to be deleted. Otherwise, you'll need to supply more specific details to help us reproduce.
Look, this isn't just some slip of the mouse I made once which I'm passing off as a bug. It's a serious bug that that must have happened to me a hundred times by now. If you can't reproduce it, then your software doesn't have the bug. I've explained the exact steps required to reproduce it. I'd previously only noticed this in Kwrite/Kate, but after further testing I've observed the behaviour in Dolphin, Konqueror and any KDE 4 app which has some sort of box where you can type text. I can't reproduce it in KDE 3 or Gtk applications. Opera (a Qt3 app) also does not suffer from this. Perhaps it is a Qt4 bug. Since I use Compiz to switch between apps, I tried disabling Compiz and re-enabling Kwin's native Ctrl + Tab switcher, but the bug persists.
Without anybody being able to reproduce this its not fixable. Besides, nobody else having this problem highly indicates a problem specific to your system - a setup problem or broken software.
You not being able to reproduce it != nobody being able to reproduce it. Anyway, thanks for giving me a clue that it might be something fixable via configuration files. I've just spent a huge amount of time removing files from my home directory, logging out, logging in again, and seeing if they affect the problem. I finally isolated the problem. There's a symlink that points from ~/.xinput.d/en_GB to /etc/X11/xinit/xinput.d/scim-bridge. In that file, there is an if command like this: # BEGIN QUOTE if [ -e /usr/lib/qt3/plugins/inputmethods/im-scim-bridge.so ]; then QT_IM_MODULE=scim-bridge else QT_IM_MODULE=xim fi # END QUOTE That makes the input of languages with complex scripts possible on KDE3/Qt3. The IM module is provided by the package "scim-bridge-client-qt". It also works for KDE4/Qt4, but it causes the text-deletion bug in all KDE4/Qt4 apps. If I alter the above so that it uses "QT_IM_MODULE=scim-bridge-kde4", then it starts using the files from the "scim-bridge-client-qt4" package, and there is no more text-deletion bug! However, it then totally disables the input of complex scripts for Qt3 apps (e.g. Opera, VirtualBox, and anything from KDE3). It doesn't seem to be possible to separately set the environment variable "QT4_IM_MODULE". So, the user must choose whether he wants Qt3 or Qt4 apps to work properly. This is a major bug, but it's in scim-bridge rather than KDE.
+1, Debian packages. Selected text is deleted on window switch. No KWin composite active. Please reopen.
This bug seems originally not to stem from kate/katepart. I could reproduce this bug using the testcase posted for bug 168226 which includes a KTextEdit widget. I can't though reproduce this for Konqueror which, as far as I know, uses a KTextEdit for text input (e.g. this comment field).
Sorry, Christoph. I don't get the relevance of that python thing you linked to. It's over my head. Are you sure that this bug needs to be reopened?
The application I linked to is just another example where selected text gets deleted, thus indicating that its not only a problem with kate. I guess we have to digg somewhere else, so I wouldn't reopen anymore.
FYI: I filed a more general bug report for my distro: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494752
Created attachment 27288 [details] A stack trace of an occurence of the bug I filed this bug with a stack trace and a proposed patch for scim-bridge as a Fedora bug. Please review if my analysis of the problem is correct. https://bugzilla.redhat.com/show_bug.cgi?id=461373 I attach the stack trace here as well.