Me vs Backspace: my war against a rogue character | Hacker News Reader

Me vs Backspace: my war against a rogue character

lbrandy.com

81 pointsspydez31 comments

This would be a good time to point out that OSX supports Emacs bindings in all Cocoa text fields.

For example, you can press ctrl+a to go to the beginning of the line and ctrl+e to go to the end of the line. The "Meta" modifier can be accessed via alt+ctrl, so you can alt+ctrl+f to go forward a word, or alt+ctrl+b to go back a word. Any motion can be combined with shift to select the text.

These are especially useful with the laptop keyboards. Bonus points if you convert your caps lock key into an additional ctrl key: http://mkaz.com/archives/86/disable-caps-lock-on-mac-os-x/

alternatively, for Terminal, set -o vi

I also bind H to ^ and L to $ with

bind -m vi 'H: vi-first-print'

bind -m vi 'L: end-of-line'

(not OS X specific, but related)

Jacob Rus has an excellent and thorough write up of the Cocoa Text system: http://www.hcs.harvard.edu/~jrus/Site/Cocoa%20Text%20System....

He provides a custom DefaultKeyBinding.dict which adds more emacs keybindings to Cocoa text controls. I've been using it for years: http://www.hcs.harvard.edu/~jrus/Site/KeyBindings/Emacs%20Es...

Unfortunately it's missing the most crucial Emacs bindings: C-s and C-r.

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.

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 ;)

"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.

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))

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.

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?

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.

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

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.)

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.

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.

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.

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.

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.

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

I've verified this issue using TextEdit saving the file and printing it using "od -a".

I've also submitted it to bugreport.apple.com as bug # 8223684

Interesting. In my text editor (TextMate), I can reproduce this pretty reliably using that key sequence.

Video: http://www.youtube.com/watch?v=wLMNin-2p6A

Here is another article I found on this, "Mac Delete Key Bug Demonstration".

http://gunther.web66.com/crossjava/Bugs/deletekeybug/

That's a different bug and is only relevant for Java apps. On a Mac, the backspace key is labeled "delete", and the key associated with the action most people refer to as "delete" is labeled with the delete special character[1]. Apple refers to this as the "forward delete" key. The bug described at the link you provided does not require the shift or arrow keys to be pressed and produces a different control character.

1 - http://en.wikipedia.org/wiki/Delete_key

Fun historical note: The original Mac keyboard had a Backspace key rather than a Delete key. http://www.vectronicsappleworld.com/collection/articlepics/5...

The current Mac "Delete" key was inherited from the Apple IIgs ADB keyboard, and it stuck around.

I decided to wipe my Mac, reinstall the OS, and see if that fixed it.

So reinstalling the whole OS was higher up the troubleshooting chain than just trying it out from your wife's computer? Err...

Piffle. Sure you can make that criticism after he told you the answer. Could you have told him before?

If you've never done the equivalent, it's only because you haven't been around computers very long.

If you've never done the equivalent, it's only because you haven't been around computers very long.

Dude, in twenty years with computers I have never re-installed an OS to fix a problem (obviously this is distinct from installing a new version of the OS which could legitimately have a fix for it). For me rebooting the computer is even a last act of desperation that I am ashamed to take.

But then I am a unix/Linux user. I grant you the possibility that this may somehow have been a rational act for MacOS, though if true I find that disappointing.

So reinstalling the whole OS was higher up the troubleshooting chain than just trying it out from your wife's computer? Err..

I think you are suggesting a non-causal solution. What exactly is this "it" you think I should have tired on my wife's computer? The character never appears in my normal mac usage. So despite the fact that I use her computer all the time, I never noticed it happening (though I'm sure it did) from her computer.

Yep. You encountered a totally insidious, elusive bug. Even if you had tried it from your wife's computer, it probably wouldn't've shown up then.

At the time, all you had to go on was that there was a probable misconfiguration somewhere in the deep, dark innards of MacOS, and the best way to handle that particular problem is to nuke it from orbit.

I do all the shift+arrow text marking with my right hand solely, incl. cmd+backspace (delete) - and so, I never run into the problem of accidentally inserting the $08 character anywhere.

But, yes, you are right, holding shift+any arrow key, while hitting backspace, inserts a $08 by the OS X IME. This does depend on what kind of dialog you are writing in (NSTextField, NSTextInput etc.), however, as not all of them accepts this input. You can't input a backspace character this way in Terminal.app, f.e.

Reply on news.ycombinator.com