Inconsistent cut-and-paste behaviour

Bug #57415 reported by James Baum on 2006-08-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)

Bug Description

Cut-and-paste behaviour on linux has deteriorated during the last decade or so and is now very inconsistent. This applies to a number of applications, so I'm not sure which package to report it against.

There are two main ways to put text in the cut-and-paste-buffer: the X-windows way and the Microsoft way. Guess which is better.

The X-windows way is to mark text with the left mouse button (by holding and scrolling, letters or lines at a time or by double-clicking for a word or triple-clicking for a whole line). Marking text automagically copies it into the buffer - a Good Thing(TM).
Pasting is done using the middle mouse button or by using SHIFT+Insert, a sensible use of the Insert key.

The Microsoft way is to mark first and then have to use CTRL+c (used for completely different things in a *nix shell) to copy to the buffer. Pasting is done with CTRL+v. This is at best inferior to the X-windows way. IMNSHO it's broken by design.

In the good old days things were done the X-windows way and everything worked just fine. Then applications which use the Microsoft way were ported to linux and introduced a inconsistency. New OSS developers who were used to Windows and didn't know better also developed applications using the Microsofts paradigm.

Now there are (at least) two cut-and-paste buffers in "linux", and they're not synchronized.

Affected applications include
opera (ok, it's not OSS)
Klipper (KDE clipboard tool, which even has a preference "Synchronize contents of the clipboard and the selection" but which doesn't always seem to fix this issue but illustrates it very well)
most xterm-clones
X-chat (broken marking of text, you have to press CTRL+c whilst holding the mouse button down, which is more broken than most)

I think that there are two goups of applications, I'm not sure how to fix the bug. Maybe just synchronizing the "CTRL+c"-buffer with X's buffer would fix it. If the way klipper fixes it is the right thing to do then it should at least be enabled by default (I think it isn't). Since klipper is KDE Gnome may have similar problems.

For american lawyers:
All trademarks are the property of their owners. By the definition of "property" and "owner". Duh.

Simon Law (sfllaw) wrote :

Thank you for your report.

This behaviour has always been the case and is a design feature of X11.

You are describing SELECTION and PRIMARY buffers. They were separate
and have semantics that are both supported by major X applications. It
is unlikely that this will change in the near future, even though more and
more applications prefer exposing the PRIMARY buffer in their menu

Changed in xorg-server:
status: Confirmed → Rejected
James Baum (james-baum) wrote :

This is a major usability bug which makes this feature of Ubuntu/linux desktop usage inferior to alternatives. If bug#1 is to be fixed this should also be fixed.

Maybe this is a good thing in the X server. Despite that the window manager should implement a decent workaround.

Fred (eldmannen+launchpad) wrote :

Yeah, the Windows copy&paste sucks and inferior to the X-Windows way...

Right, but at least in Windows you can paste data even after you closed the application from which you copied the text. Now that is more than I can say for X.

This you could done 15+ years ago in Windows 3.11, still cant do it today on Ubuntu 8.04 (alpha) + updates.

But yeah, the Windows way is the inferior one...

Remember "Worse is better".

FMaz (fmaz008) wrote :

This bug has been mark as a duplicate of the bug #11334, called: "MASTER Copy-Paste doesn't work if the source is closed before the paste"

If this bug still affects you, please use the "This bug affect me too" option to increase the resolution priority:

The full bug repport can be seen at:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers