Recently I've been busy working on things (i.e. coding) from the Linux workstations at Uni.
During this time, I've also run into an annoying "feature" which has been causing me endless grief: MMB paste. I'd first encountered it about 3 years ago, but at the time blamed a particularly crappy little IDE for being that cause of that with some potentially weird keymappings. However, in recent times, this has started becoming a significant productivity killer, having struck on average 1-2 times a session over several days.
Modern 3-button mice usually have a scrollwheel as their "middle" button. That is, you rotate/spin the donut shaped "scrollwheel" button to scroll through documents or zoom while holding a modifier key. You can also press this wheel down, making it act as the third mouse button, otherwise referred to as MMB.
Back when most Unix/Linux stuff was really still quite primitive (i.e. serious-hacker-enthusiast-level-only, 1990's), I believe that most mice back then were either 2-buttoned, or if they were 3-buttoned, they didn't have scrollwheels back then. Understandably, for these hackers, that third/extra button would've been seen as a novelty, a button onto which a frequently performed action (pasting text) could be assigned. All fine and well back then, where mice with 3 buttons actually had a middle-mouse-button not a middle-mouse-wheel.
So, what is the harm?
Well, it turns out that it is all too easy to inadvertently end up corrupting documents and code when scrolling around the document frantically trying to find something. It seems that sometimes, such frantic rolling of the scrollwheel might end up getting misinterpreted by some mice as being a MMB click (even though you wouldn't feel the usual *clunk* that's associated with such)!
Lo and behold, after scrolling up 3-5 pages in a hurry, you've now managed to corrupt your code in sometimes weird and confusing ways, as somehow the contents of your copy+paste buffer have now been splattered in the middle of your code, wherever the mouse pointer may have been when a scroll was initiated. In nearly every case, the consequences are confusing: if you happen to have a large hunk of code in your c+p buffer, then all of a sudden, your codebase has grown several 100%; if you happen to have just a single character (or perhaps a very short variable name or snippet), then it's perhaps even worse, as the corruption is even harder to spot!
Inevitably, time then gets lost trying to track down exactly where accidental insertions had occurred (usually since you only really realise after performing some editing at your destination, start encountering some odd code on the way back down, and realise you've been struck again). Argh! A non-destructive view manipulation operation has suddenly turned into a destructive data mangling monster.
Unfortunately, searches so far have not turned up any good solutions for this yet. The tips I've encountered so far have basically suggested remapping the MMB event at X11 level (which is apparently where this all lives) to another key altogether. While this gets rid of the MMB paste problem, it is also NOT an acceptable solution!
By knocking out the MMB event at X11 level and binding it to another or nothing (using xmodmap), it means that instead of just disabling the paste functionality of MMB, we've just killed MMB altogether, which means that we can no-longer use it to open links in new tabs and/or close tabs (in Firefox, etc.) which are features I actually make very heavy use of (NOTE: I very rarely open any links by clicking on them anymore, it's nearly always to a new tab, since otherwise I'd have to go back in the history to try and remember what other interesting links there were back on some page in the past... which is all too easy to forget after 2-page deep browsing already!).
However, surely this isn't the total extent of what we can customise! Looking at the way that most of the X11 stuff is constructed, you'd think that every little niggle is defined by some string-constant that must be explicitly bound to some input event for that handler to get fired. And MMB paste logically seems like it'd be one of those things that would be included in that category.
If not there, then perhaps it might be one layer up, at some GTK/KDE level global key mapper or perhaps within the widgets for those toolkits. But still, somewhere it would exist in a place that it could be knocked out.
So, for anyone who's got up to this point: if you (or someone you know) knows of an easy way to disable this "feature" without disabling MMB clicks to open/close tabs in browsers (and/or other apps which use this in a normal way), I'd be very interested in hearing about it.
The same goes for anyone who knows of some mystery options to tell svn not to expand keywords in files, even if it runs across them. (The file reloads after committing that induces is a pain)
It is one of the greatest features once you get your head around it.ReplyDelete
I don't know if it is the exact same or even a related issue, but I remember having middle mouse issues for Durian. My mouse wheel had scroll, middle mouse down and a tilt left and right. Which seemed to confuse ubuntu no end, usually when trying to navigate Blender's viewport.ReplyDelete
My brute force solution was to try different mice until I found one with few enough features that it worked as expected.
As far as actually reconfiguring one though, best of luck but I can't give any helpful advice.
Scroll wheels really really annoy me, an ergonomic disasterReplyDelete
Much prefer a proper 3 buttoned mouse and it's great for 3D - the old SGI 3D packages ie. Softimage used to map x,y,z axis to each of the buttons
If I wanted to scale in the Y I would just press the mmb
and besides use the scroll bars for scrolling