Using Left/Right Arrow Keys in Mathematical Text
Paul Libbrecht commented that there’s more to selection in math text than discussed in my first post on this subject. As usual, Paul is right. That post explains how one or more characters and/or math objects are selected. In addition the topic of selection includes insertion-point behavior, which by definition selects no characters or objects. The insertion point simply indicates where the next character you type or the next thing you paste will be inserted.
The present post describes how the left and right arrow keys work in and next to math zones. These keys traverse the logical backing store, generally moving one character at a time. For example typing the right arrow key successively starting at the left of the equation E = mc2 moves past (1) E, (2) =, (3) m, (4) subscript-object start delimiter, (5) c, (6) subscript-object separator, (7) 2, and (8) subscript-object end delimiter. Successive Shift right arrows starting at the left of E = mc2 also move past the first three characters while including them in the current selection. Step (4) is different for Shift right arrow, since it selects the whole object, i.e., up through (8).
Now consider a substantially different behavior, namely what these arrow keys do at the edge of a math zone. Math zones are represented by a character formatting attribute like bold. Math zones don’t begin and end with delimiter characters the way math objects do. Nevertheless, it’s desirable to make it seem as though they do, so that you can easily insert something immediately before and after a math zone, and at the beginning and end of a math zone.
To illustrate how this works, suppose the insertion point (IP) is at the start of a line immediately following a displayed equation. Typing the left arrow key moves the IP before the ASCII CR (U+000D) that terminates the displayed equation. But the nice acetate rectangle that surrounds an equation when the IP is inside the equation does not appear. Even though the IP immediately follows the math zone, it’s not in the math zone. At this point if you type a character, it won’t be in the math zone and the displayed equation will be converted to an inline equation with correspondingly compressed typography.
Typing the left arrow key another time moves the IP into the math zone and the acetate rectangle appears. This left arrow key didn’t bypass any character; it only changed the selection IP to have the math zone character formatting property. Consequently if you now type a character it will be inside the displayed equation and be formatted according to math-zone rules. In summary, to move the IP from outside a math zone to inside the zone or vice versa, type the appropriate arrow key, but no character is bypassed. Only the selection’s math-zone property is changed. So it feels as though math zones have start and end delimiters even though they don’t.
Implementation advantages to using the math-zone character formatting effect include automatic merging of adjacent math zones and prevention of nested math zones. On the other hand, it complicates the arrow-key logic. I suspect the code might have been simpler if math zones had start and end delimiters, just the way math objects do.