Mail 2.0: Non-standard aspects of line-by-line text selection

Posted by Pierre Igot in: Mail, Microsoft, Pages
March 22nd, 2007 • 5:50 pm

This one is a bit tricky to explain, so brace yourself. Here goes…

When I am in a word processor such as Apple’s Pages and I want to select a block of text, the behaviour of the text selection tool is as follows. If I start my selection at the beginning of one line and then move my mouse pointer down to the next line, Pages automatically selects the entire first line and then starts selecting characters in the second line:

Line selection in Pages

Here I have two options. Either I can continue to drag the mouse pointer horizontally to the right, which will extend the selection character by character on the second line, keep the first line entirely selected, or I can drag my mouse pointer down to the next line. If I do the latter, then as soon as the “hot spot” of the I-beam cursor enters the next line, the entire second line becomes selected as well:

Line selection in Pages

So far so good. This behaviour is pretty standard and actually works the same in all the text editors that I use, including Mail.

The difficulty starts when what I want to select consists, not of lines of text, but of empty lines/paragraphs. Let’s look first at what happens in Pages. I tried the same thing as above, but with empty paragraphs of text. I put my insertion point at the beginning of a couple of empty paragrapsh and dragged down:

Line selection in Pages

As you can see in this screen shot, even though the hot spot of my I-beam cursor still is somewhere inside the second paragraph, Pages has already selected the entire second paragraph. Why is that? Well, the paragraph is empty, so the position of my I-beam cursor here, slightly to the right of the edge of the left margin, is such that I have already selected all there is to select on that second line/paragraph. In other words, by putting my I-beam cursor slightly over to the right, I have already done the same thing as I would have done if I had dragged my mouse pointer all the way to the right end of the second line in the first example given above. In other words, because the end of the second empty line/paragraph coincides with the beginning of it—it is empty, after all—putting the I-beam cursor anywhere to the right of the edge of the left margin is equivalent to selecting the entire line, and that’s what the text selection tool in Pages does.

Compare this to what happens in Mail, however. Take an e-mail message that you are composing which contains some empty lines that you want to delete:

Line selection in Mail

Notice any difference here? My I-beam cursor’s hot spot is in a similar position to the one in the last example above, i.e. it is somewhere to the right of the left edge of the second empty line. Yet Mail still has not selected this second line!

In fact, in order to select this second line, I have to drag my I-beam cursor further down, all the way to the third line:

Line selection in Mail

Somehow I cannot get used to this. I am used to the word processor behaviour exemplified in Pages, which is also the same in Word and when editing text in text blocs in InDesign: When you drag your cursor to the right of an empty line, that line becomes selected.

Now to be fair, Mail is not unique in this respect. Other text editors, including TextEdit, and Bare Bones Software’s BBEdit, also behave in the same way, i.e. you have to drag your mouse pointer down to the next line in order to select the previous line when it’s empty.

So the problem is not that Mail is wrong and that Pages is right. It is that we have two different behaviours for an action (selecting an empty line) that is essentially the same, depending on which application we are using. On one side, you have Pages, Word, InDesign, and probably other word processors; on the other side, you have Mail, TextEdit, BBEdit, and other text editors.

(TextEdit is a bit of a funny beast. It can act as a bare-bones word processor. It’s able to open and edit RTF and even Word documents, but it behaves like a text editor rather than a word processor in many respects.)

The fact that we have two different behaviours for the same action means that we constantly have to make subconscious mental adjustments. And the manifestation of this is a perpetuation of our ever-present irritation and frustration with those damn computers that never behave exactly the way we expect them to behave.

When you add to that the different text selection behaviours that Apple has unilaterally introduced in applications such as Pages and Mail for text selection keyboard shortcuts, you get a rather poisonous mix of small inconsistencies that repeatedly interfere with your ability to work smoothly and efficiently.

As someone who uses both mouse and keyboard text selection interchangeably in all my text editors and word processors, I find all this quite irritating. What Apple is effectively expecting me to do is to remember that, when I am in Pages, mouse selection work one way and text selection keyboard shortcuts work one way, and then when I am in Word, mouse selection works the same way but text selection keyboard shortcuts work the other way, and then when I am in Mail mouse selection works the other way but text selection keyboard shortcuts work the same way, and then when I am in BBEdit mouse selection works the other way and text selection keyboard shortcuts work the other way too!

It really is not reasonable. We need consistent, system-wide behaviours that are the same in all applications and don’t require those constant mental micro-adjustments. They are just too tiring.

I know that maintaining consistency when third-party developers are involved is challenging, but Apple could at least start by leading by example. Instead, it maintains its own inconsistencies across its own applications, and also introduces new behaviours that no third-party developer is ever going to adopt, thereby forcing us to live with more inconsistencies for many years to come.

Sigh.


Comments are closed.

Leave a Reply

Comments are closed.