One of the greatest advantages digital content provides is its immediate malleability. With the right software changes can be made quickly and globally. A hallmark of this flexibility is the great big undo/redo stack that nearly every piece of software maintains.
An application normally implements undo by recording inverse operations for every action the user takes. For instance, to undo adding 10 to a particular number, you simply subtract 10. When a user deletes a word from a document, the inverse operation is to simply insert that same word back in.
Looking more closely at the requirements necessary to undo the deletion of a word, you can see that you need to know not only what the word was, but where the word was located in the document. At a lower level this location is simply the number of characters that preceed the deleted word.
For instance, imagine a document containing only the text “ice is blue”. Note that the word “blue” is preceded by a total of 7 characters. So to undo the deletion of the word “blue” from the document, we simply insert the word “blue” after the 7th character in the document.
Locations are complicated by document content that automatically updates itself. One example might be a timestamp. One second the stamp could read “Thursday 23:59”, the next, “Friday 00:00”. You can see that the stamp shrunk by 2 characters. Had our imaginary document in the previous paragraph contained a timestamp such as this one, the location we need to reinsert the word “blue” at to undo the deletion would have changed. To accommodate undo after a timestamp we need to be able to describe locations in the document like “the 7th character after the 2nd timestamp”.