Fixing Copy-Paste issues on Eclipse and KDE
This article describes a solution to fix a long term issue (bug?) involving copy & paste when running Eclipse on KDE.
The problem
When launching Eclipse from KDE, one might experience several types failures with cut, copy and paste actions in Eclipse. The reported misbehavior is non-deterministic, but frequent enough to degrade user experience.
Inside the editor, specially the Java or C/C++ editor, selecting text and issuing the copy action (ctrl+c or equivalent menu entry) may not copy the select text to the clipboard (no text is copied).
The cut action (ctrl+x or equivalent menu entry) erases the selected text as expected, but may not save to clipboard (text that was cut is lost!).
Even worse, after the selected text was apparently copied (or cut) correctly, the past command (ctrl+v or equivalent menu entry) does always write correctly from clipboard. Sometimes, paste only writes part of the expected text (part of the text is lost).
Fortunately, copy & paste or cut & paste does not corrupt text, it only looses text frequently.
Copy & paste never fails on text boxes in dialogs. It might fail only on text editors.
Workarounds
At the end of this article I will explain other two workarounds. But here are the simplest ones first:
In order to copy text, one may press ctrl+c twice. The second ctrl+c always copies the selected text to clipboard.
Now, to cut text, one may press ctrl+c, then ctrl+x. It happens that pressing ctrl+c first induces ctrl+x to work correctly.
When pressing ctrl+c twice or ctrl+c followed by ctrl+x, paste always works.
Deeper investigations
On KDE, copied or cut text is intercepted by the Klipper deamon, which manages KDE global clipboard. Klipper provides copy & paste compatibility among X applications. For example, with Klipper, a generic X application can copy to/from KDE application, although they do not use the same copy & paste protocol. Klipper also overcomes some X protocol limitations related to copy & paste feature. Furthermore, Klipper offers clipboard history.
With Klipper, I was able to inspect what Eclipse did actually copy to clipboard when pressing ctrl+c. I noticed that:
- If “copy” was successfull, then the most recent entry in Klipper history contains exactly the text that was copied.
- Sometimes eclipse inserts an empty entry into Klippers history, instead of the expected text. An empty string will be pasted, not producing any effect.
- Frequently, the copied text appears in Klippers history, but split into several entries. In this situation, “paste” will only write the last entry. After the split, some entries may be missing.
It is even more interesting that if text becomes split in Klipper, it is not split at random chars, but on points relevant to the semantics of the text that you are editing in Eclipse!
For example, I copied the second line of Java code:
try {
updateLaunchConfigurationDialog();
} catch (Exception e) {
Plugin.log(e);
}
After copying the second line, “paste” produced only “updateLaunchConfiguration”, but “Dialog();” was missing. For example, on Java, if copy happens to fail on a name of a variable or a method, it always splits on a uppercase letter that starts a word of a composed name. On expressions, it copy may split exactly on delimiters or operators.
The fix
Or maybe, we should call it: Yet another workaround.
The drastic one: Remove Klipper from your taskbar. Besides clipboard history, you will potentially loose compatibility among X applications.
Another one: Open Klipper configuration dialog and uncheck ‘Prevent empty clipboard‘ in Klipper’s settings. The advantage is that you keep benefits of Klipper and only disable the feature that is known to interfere with Eclipse. But once you close an application, content that was previously copied on this application will not be available for pasting anymore.
I think that the last workaround does not solve the problem, but it is the less intrusive workaround.
In future, I will explain in another article, who we should claim about this issue: Eclipse or Klipper?

