SUMMARY This is an intermittent error, but very annoying. It also occurs when I'm running Debian. Sometimes, when I try to copy text from one spot in a document to another location, the same text is pasted in several places, often far removed from the "target" location where I had positioned the cursor before hitting "Ctrl + v" (^v). STEPS TO REPRODUCE 1. open any text document. select some text, hit ^c or ^x 2. move the cursor somewhere else and hit ^v. 3. usually this works the way it's supposed to. 4. but if you do it often enough, the bug will eventually bite you. OBSERVED RESULT Pastes text in locations far removed from the cursor's location when ^v is pressed. EXPECTED RESULT Pastes the copied text only where it's supposed to. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: ✔ (available in About System) KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.55.0 Qt Version: 5.9.7 ADDITIONAL INFORMATION Kate has been my preferred text editor for many years. Up until about two months ago, I had never experienced this problem. It only started happening after I switched from Kate 17.12.3 (under openSUSE LEAP 15.0) to Kate 18.12.3 (LEAP 15.1). The past couple of months I've been working on KDE documentation, so I have been using the text editor a lot. The first few times this happened I was totally confused. I would make a small change near say line 2000 of an XML document, and when I ran "checkXML5" it would report errors at lines 46, 500, and 750. The errors were caused by text getting inserted in a bad spot (like after a </para> tag, and before the following <para> tag). I started using Kwrite instead of Kate, but the problem persisted. So now I'm using gedit to do most of my text editing. I haven't had this problem with the gnome text editor ... just the KDE versions.
Hmm, can not really reproduce that here. Is there a chance that you could update your KDE Frameworks version?
(In reply to Christoph Cullmann from comment #1) > Hmm, can not really reproduce that here. > Is there a chance that you could update your KDE Frameworks version? Probably not. I'm not ready to try compiling something as complex as that from source. I'm basically a user who depends on pre-compiled binary packages, who *used* to be a programmer (IBM mainframes, in assembly language, mainly -- I'm old), and who is willing to help write KDE documentation. I have observed this bug on three different Linux platforms, all of which are installed on the same PC (Dell XPS 8930). Neon 5.16.4 (Plasma 5.16.5 Frameworks 5.62.0 Qt 5.13.1) SUSE LEAP 15.1 (Plasma 5.12.8 Frameworks 5.55.0 Qt 5.9.7) Debian 10.0 (Plasma 5.14.5 Frameworks 5.54.0 Qt 5.11.3) Kate / Kwrite version is 18.12.3 on SUSE, 18.08.0 on Debian. I don't have either Kate or KWrite installed on the Neon system any longer. That is where I first noticed the problem (in late August). I eventually moved my KAddressBook documentation project to the SUSE platform, and only used Neon for "arcanist", to upload stuff to Phabricator. I uninstalled Kate / KWrite because there were already enough updates to apply every time I booted into Neon. As a former programmer, I understand that this is the worst kind of bug, because it doesn't happen very often, and it's almost impossible to reproduce. I don't suppose it will get resolved unless a lot of other people also report it. Not to worry ... I haven't had the problem with gedit, and Kate / Kwrite works fine when I'm editing smaller documents. So I can patch around the problem. I didn't report this as a bug for about two months after I first noticed it. I knew Neon was buggy because there are a lot of new packages going in regularly. I finally decided to file this bug after it bit me on three different platforms. It generally happened with very large documents (2,000 lines of text, or so). I am certain it did in fact occur many times -- I would copy a small snippet of XML text (or straight data, like half of a sentence) and paste it in exactly one place (^C and ^V -- I rarely use the edit menu -- force of habit, I suppose), but when I ran "checkXML5" (a syntax checking program for .docbook files written in XML), it would report four or five errors, which were usually about CDATA (text appearing in areas between XML tags that ought not contain anything except white space) or breaking the DTD rules (XML tags appearing somewhere where the syntax rules said "No way, José"). When I tracked the errors down, they were all exactly the same "CDATA" or XML code sprinkled around the document in locations far away from the place where my cursor had been when I hit ^V. And I always recognized the errant character string as a bit of text I had copied from one spot to another during my previous editing session. Thanks for looking into it, Christoph!
No, I didn't imply that you need to compile that stuff, just wanted to know if you can try with a more up-to-date version. But you did that already given you state below Neon 5.16.4 (Plasma 5.16.5 Frameworks 5.62.0 Qt 5.13.1) SUSE LEAP 15.1 (Plasma 5.12.8 Frameworks 5.55.0 Qt 5.9.7) Debian 10.0 (Plasma 5.14.5 Frameworks 5.54.0 Qt 5.11.3) I would really like to fix this, but after inspecting the code a bit, I can't think of any "obvious" reason this should happen :(
(In reply to Christoph Cullmann from comment #3) > No, I didn't imply that you need to compile that stuff, just wanted to know > if you can try with a more up-to-date version. > > But you did that already given you state below > SUSE LEAP 15.1 (Plasma 5.12.8 Frameworks 5.55.0 Qt 5.9.7) > Neon 5.16.4 (Plasma 5.16.5 Frameworks 5.62.0 Qt 5.13.1) > SUSE LEAP 15.1 (Plasma 5.12.8 Frameworks 5.55.0 Qt 5.9.7) > Debian 10.0 (Plasma 5.14.5 Frameworks 5.54.0 Qt 5.11.3) > > I would really like to fix this, but after inspecting the code a bit, I > can't think of any "obvious" reason this should happen :( I honestly doubt that the problem is in Kate itself. But I had to report it somewhere if I wanted to report it at all. Let me explain. About a year ago I noticed a change in the way the "Clipboard" works. Previously (on SUSE LEAP 42.3, and going all the way back to SUSE 9.0, starting in 2003) I could select a block of text in just about any program whatsoever, and it would not be copied to the "Clipboard" until I hit ^C, or ^X. When I installed LEAP 15.0 (December, 2018) I noticed a change. Text was automatically copied to the "Clipboard" as soon as it was highlighted (either by dragging the mouse, or by holding Shift and striking --> on the keyboard). This was very annoying for a while, because I had been in the habit, when surfing the web, of selecting a URL somewhere (with the right-click context menu in Firefox --> Copy Link Location) and then pasting it in the navigation bar of a Firefox tab that was already open. The new behavior of the "Clipboard" made this procedure more difficult, because when I selected the text I wanted to replace with the copied URL, a new entry was made in the "Clipboard"'s stack of saved items, effectively erasing the new data I was trying to copy. So I had to either open the "Clipboard" from the system tray and move the data I wanted to copy back to the top of the stack, or alter my old habits and erase the text I wanted to replace (with backspace, or delete) instead of just selecting it and then overwriting it with ^V. The new procedure wasn't any more work than the old procedure, but old habits are hard to break. I still have trouble with the recent change in "Clipboard" behavior. Anyway, I don't have the trouble with Gnome programs like gedit (I have configured both Debian and SUSE with multiple desktops on my new PC). I don't log into the Gnome environment very often, because I've used KDE since 2003, and I'm used to it. But I can invoke gedit from either desktop. Anyway, the "Clipboard" is different in Gnome -- I don't think there's a stack of saved items in that environment, because there isn't any system tray. At a minimum, if there is a stack, I don't know where to find it. To make a long story short, I suspect that KDE sticks its "hooks" pretty deep into the Linux / X11 environment to maintain the stack of items on the "Clipboard" that appears in the system tray, because ^C and ^X work just about the same way in every program that runs (including things like LibreOffice, and Firefox). I'm not really an expert on Linux internals. But I wrote a lot of programs in assembler (almost machine language) on IBM mainframes, so I know that "system-wide" features can do unexpected things, because i/o interrupt routines are very hard to get exactly right. (^C and ^V cause interruption events, which are buffered inside the keyboard and passed through to the PIC / CPU on the motherboard at somewhat sporadic intervals, as I understand it.) Thanks again for helping, Christoph. If I think of something else that might be useful information, I'll report it here.
David do you still experience this issue in more recent versions of Kate/Framework/Plasma?
(In reply to Justin Zobel from comment #5) > David do you still experience this issue in more recent versions of > Kate/Framework/Plasma? No. It was apparently related to an old version of KWrite, or maybe Klipper. I finally got brave enough to build Gentoo Linux. Kate is now version 20.04.3, Frameworks is 5.74.0, qt 5.15.1, and I haven't had this problem -- not even once -- since I got Gentoo working (about four months ago). I guess we should close this bug. Thanks for asking. :-)
Thanks for the reply David, enjoy Gentoo!