Betalogue

I have already written a post about the fact that, in Pages 3.0, when you are editing text inside a table cell, the standard keyboard shortcuts for extending the selection to the beginning or the end of the current paragraph, i.e shift-option-Up and shift-option-Down, no longer work as expected.

When editing text inside a table cell, instead of doing the expected, i.e. extending the selection to the beginning or the end of the current paragraph, the shortcuts are actually interpreted by Pages as commands for adding new rows above or below the current table row. Argh.

But the situation is actually worse than that. First of all, the problem also affects the keyboard shortcuts for extending the selection word by word to the left or to the right, i.e. shift-option-Left and shift-option-Right.

The additional quirk for these last two shortcuts is that, if you use them inside a paragraph of text, they work as expected (i.e. they extend the selection). But once you reach the very beginning (or end) of the text in the cell, then Pages hijacks them again and interprets them as commands to add new columns to the left or to the right of the current tablecolumn. Argh.

Here’s an example of a table cell where I have selected a word and extended the selection to the left (i.e. to the previous word, which is actually on the previous line because of the text wrapping) by pressing shift-option-Left once:

So far so good. Now I press shift-option-Left once more to extend the selection by one more word:

No problem here. But now I have reached the beginning of the text in the cell. Look at what happens if I use the shift-option-Left shortcut once more:

Argh. Pages has not only added a new column to the left of the current one, but also lost my selection in the process.

Why is this such a problem? Because when you are a regular user of keyboard shortcuts for text navigation and selection, such as myself, you use them all the time and often repeatedly, in quick succession, in order to select a bunch of words. And sometimes you overshoot by using the shortcut once too many. It’s perfectly normal. But in such situations you would expect Mac OS X to ignore the extra keystrokes.

Instead, Pages has a very destructive behaviour where, once you reach the beginning or the end of the cell, the meaning of the shortcut changes, the selection is lost, and unwanted columns get added to the table. It is not good, and I frequently encounter the behaviour, which effectively punishes me for using text selection shortcuts in Pages. (It looks like Apple’s own engineers never use these shortcuts themselves.)

It gets even worse. The problem affects not just tables in Pages, but also tables in Numbers. Both applications share a number of behaviours when it comes to tables. Unfortunately, they also share this dual use of the shift-option-Up, shift-option-Down, shift-option-Left, and shift-option-Right shortcuts both for text selection and for adding rows and columns.

Interestingly, however, the behaviour in Numbers is not exactly the same as it is in Pages. If you take the scenario described above, and try to use the shift-option-Left shortcut repeatedly inside a table cell in Numbers in order to extend the selection to the left, when you hit the edge of the cell (i.e. the beginning of the cell’s contents), Numbers actually does the right thing and simply ignores additional occurrences of the shift-option-Left shortcut. It does not hijack the shortcut by interpreting it as a shortcut for adding a new column before the current column.

Numbers only interprets shift-option-Left as a shortcut for adding a new column before the current column when the cell itself is selected, not the contents of the cell. (Like Pages, Numbers has two selection modes in tables: a cell selection mode, and a text selection mode when editing the contents of a cell.)

It is much better, because it means that you can overshoot with repeated shift-option-Left or shift-option-Right shortcuts inside a table cell in Numbers without running the risk of accidentally insert new columns. And Numbers is similarly smart about interpreting the shift-option-Up and shift-option-Down
properly when editing text inside a cell, i.e. it correctly extends the selection to the beginning or end of the paragraph and does not add new rows.

Numbers only interprets the shortcuts as commands for adding new rows or columns when the cell itself is selected, without being in editing mode inside the cell.

I still do not agree with the dual use of these shortcuts, even in Numbers, but at least Numbers does not let the two functions of these shortcuts interfere with each other while editing text inside a table cell.

Sadly, the third member of the iWork ’08, Keynote 4.0, suffers from the same flaws as Pages 3.0, i.e. it does let the two functions of these shortcuts interfere with each other while editing text inside a table cell.

The bottom line here is that, if Apple’s engineers really insist on using the text selection shortcuts as shortcuts for adding rows and columns as well, at least they should implement the dual meaning properly, like they did in Numbers, in all iWork applications, including Pages and Keynote.

Until they do that, Pages and Keynote users who are regular users of these text selection shortcuts will continue to be punished on a daily basis when they attempt to use these shortcuts in tables and end accidentally adding rows and columns to their tables.

This entry was posted by Pierre Igot on Thursday, April 10th, 2008 at 9:16 am and is filed under Macintosh, Pages. 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.