[TrevorBramble]

Reminds me of finding out the hard way that "paste" is bound to Mouse3 by default in Gnome and that on some mice I'll occasionally scroll the wheel violently enough to trigger clicks.

Took a few times of finding random text in my code to realize what was happening, and even longer to figure out how.

[moultano]

Another hilarious consequence. Firefox, if you try to middle click a link and miss, would try to interpret whatever is in your paste buffer as an url. It would do an i'm feeling lucky search on google and send you to that page.

For a long time I thought that opening links in a new tab would sometimes take you instead to a random page on the internet.

[zootm]

You can get around this by turning on the "autoscroll" feature, since that's activated by a middle-click. I've often wondered just who exactly Mozilla thought the "paste in window goes to URL" feature was for; feels like the sort of thing that gets left in because its fanbase includes one of the developers.

[w1ntermute]

It's a Unix thing, and AFAIK, only exists in the Linux version of Firefox. By the way, you don't have to disable the autoscroll feature to disable this; just go to about:config and toggle middlemouse.contentLoadURL to false.

[nkurz]

I use it, like it, and miss this in Chrome. Rather than aiming for the address line, I can just drop a link anywhere on the page.

Perhaps it's a Linux thing. When I'm on Macs I also have trouble remembering that I have to explicitly 'Copy' things before I can paste them.

[mcantor]

"I'm telling you guys: This feature is going to be SWEET."

[jmillikin]

This isn't Gnome, it's X11 -- if you select text with the mouse and then middle-click, it'll paste whatever you selected. Luckily, the X11 clipboard is separate from the Gnome clipboard, so Ctrl-C/Ctrl-V continue to work properly after selecting something.

I haven't figured out how to disable the X11 clipboard yet. If you find a way, please post it ;)

[philh]

X11 actually maintains three separate cut/paste buffers - primary (which you access with select/middle click), secondary and clipboard. Ctrl-C/Ctrl-V are probably interfacing with the X11 clipboard, not a distinct Gnome clipboard. (Though I don't use Gnome myself, so I can't check.)

You could probably write a daemon to keep the primary selection empty. The `xsel` program would be a good place to start. I thought you could do it with `while true; do echo -n '' | xsel -n -i; done`, but it quits immediately if the input is empty so that would be constantly executing a new program. Still, I expect there's some trickery you could do with it, or you could look at how it's implemented and copy that.

(edit - or to eliminate a lot of the pain,

    while true; do echo -n ' ' | xsel -n -i; done

will keep a space permanently in the selection. I tested and it seemed to work, though there may be edge cases I'm not aware of.)

[jmillikin]

Gnome and KDE both use the freedesktop.org clipboard manager specification, not the X11 clipboard. After copying text A with ctrl-c, then selecting different text B, the X11 clipboard (xsel -b) is empty and the primary selection (xsel -p) is B.

The major advantage this has over the X11 clipboard, IMO, is that text persists after its source application is closed.

[randallsquared]

"Luckily". That's not how I'd put it. :) I really like using the X11 clipboard, and the fact that copying and pasting is inconsistent (it seems like some applications have their own, third clipboard!) is very frustrating under X11. Of course, the behavior of selecting everything when you single click in a field (like a web browser URL bar) destroys this functionality, too.

[moe]

very frustrating under X11

Personally I find it amusing this "feature" has survived all this time, all the way into modern linux desktops.

Inertia is a powerful beast indeed.

I understand the reluctance to throw out such decisions, even if they were made over 20(!) years ago, because inevitably the vocal minority will jump out of the woodwork and declare how they can not possibly live on without this feature.

However at some point common sense has to take precedence in UI design. Otherwise you end up with a trainwr^W^Wthe linux desktop.

[thristian]

No UI design perfectly suits every human; every UI design requires some level of adaptation to use efficiently. UIs that optimise for discoverability already exist; Windows and Mac OS X both do fairly well. The traditional Unix desktop has a different focus - why must people who use the traditional Unix desktop and are happy with it be forced to adapt to something else? Why can't we all just get along?

Put another way, the iOS interface, by rapidity of adoption alone, would seem to be far superior to traditional desktop-paradigm UIs. Would you agree that "common sense has to take precedence" and Windows and Mac users should have to abandon their systems and use iPads instead?

[moe]

No, but having used the linux desktop for over a decade (last stop was the ion3 wm) and now OSX, I have come to the conclusion that some of the wrongs with X11 just have no excuses anymore.

While there may still be (weak) arguments for preferring "select-to-copy" over "CTRL-C-to-copy" there is not a single argument for maintaining the mess of multiple inconsistent copy/paste methods in parallel.

This is not a matter of polish, preference or imitating what others do. It's a matter of finally applying the no-brainer lowest baseline of common sense.

[almost]

I really really hate when that happens. It was driving me mad with Emacs for a while until I added this to my .emacs:

    (setq x-select-enable-clipboard t)
    (if (functionp 'x-cut-buffer-or-selection-value)
         (setq interprogram-paste-function 'x-cut-buffer-or-selection-value))

[thwarted]

Alot of the corner cases of dealing with clipboard/selection in X seemed to go away for me when I started using Parcellite.