Betalogue

This is something that I am having a hard time getting used to, yet it appears that Apple is trying to enforce it as some kind of standard behaviour.

The keyboard shortcuts option-Left and option-Right are used to navigate text word by word with the keyboard. (option-Left moves the cursor by one word to the left, and option-Right by one word to the right.)

Take an application such as TextEdit or Pages or Mail. Type several paragraphs of text.

Now place your insertion point at the very beginning of one of the paragraphs, and press option-Left.

You’ll see that a single option-Left keystroke causes the insertion point to jump to the beginning of the last word in the previous paragraph. Now press option-Right once. Instead of returning the insertion point to the position where it was before the option-Left keystroke, i.e. to the beginning of the next paragraph, Mac OS X moves it… to the end of the last word of the previous paragraph.

It even does this when the two paragraphs are separated by an empty one, i.e. by a double return character!

This is the standard behaviour in Apple’s own Mac OS X applications, such as Pages, Mail, and TextEdit (or any application with multi-paragraph text editing capabilities, including Safari). But it’s not the standard in non-Apple editors. Both BBEdit and Microsoft Word, for example, consider that the space between the end of one paragraph and the beginning of the next one counts as a word. So if you put your insertion point at the beginning of the first word of a paragraph and press option-Left, BBEdit and Word move the insertion point to the end of the last word of the previous paragraph, and you have to press option-Left a second time to move it to the beginning of the last word of the previous paragraph.

If you have an extra empty paragraph between the two paragraphs of text (i.e. a double return), then that extra paragraph also counts as a word.

The problem with Apple’s behaviour is that it breaks one of the fundamental, unspoken rules of text navigation with cursor keys, which is that a single left keystroke should always be undoable with a single right keystroke. In other words, if I do option-Left followed by option-Right, my insertion point should stay in the same place.

With Word and BBEdit, it does. With Apple’s applications, in this particular situation (between paragraphs), it doesn’t.

To Apple’s defense, things are not exactly that simple. In actual fact, even in Word and BBEdit, there is already an accepted exception to the rule, when it comes to the spaces between words. For example, if you have a text with “wordA wordB” and you place your insertion point before “wordB” and press option-Left followed by option-Right, the insertion point ends up at the end of “wordA,” not at the beginning of “wordB,” where it was initially.

So it looks like Apple took this exception to the rule when applied to the spaces between words inside a paragraph, and extended it to the “space” between paragraphs. I supposed that, in a way, it makes sense.

The trouble is that Apple did so unilaterally (as far as I can tell), which means that, for many years (if not forever), the user is going to have to deal with inconsistent behaviour depending on which application he’s using. Somehow I highly doubt that Microsoft will ever embrace Apple’s way of doing things here. And, as far as I can tell, the Bare Bones folks are highly reluctant when it comes to changing established keyboard shortcut behaviours. (They still use option-Up and option-Down to jump up or down by one “screen,” even though the shortcuts are used to jump up or down by one paragraph in all other applications.)

Even more important, I am afraid that the behaviour adopted by Apple is too disconcerting. It’s one thing to automatically adjust the movements of the insertion point by one space character to the left or to the right when jumping from word to word. It’s quite another to have an option-Left shortcut that behaves as if paragraph breaks and final punctuation marks did not count in text navigation.

Sure, technically they are not “words,” much in the same word that spaces between words are not “words” either. But it’s quite easy to imagine a number of scenarios where treating them as words is much more convenient than the opposite — whereas in the case of spaces between words the benefits of by-passing them outweigh the drawbacks.

Maybe it’s just that I am too accustomed to the standard behaviour in applications such as Word and BBEdit. But again, unless Apple manages to unilaterally enforce its own way of doing thing on all software developers, we’re going to have to live with yet more inconsistency for many, many years. Was it really worth it, Apple?

This entry was posted by Pierre Igot on Wednesday, August 17th, 2005 at 3:05 pm and is filed under Macintosh. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.