In computer graphics, there are a couple common spatial subdivision data structures that can quickly tell you whether a particular point in "world" space is inside, on, or near an object in that world.
The ones I've worked with are all essentially trees of nested volumes. For example, a bounding volume hierarchy is a tree of nested volumes (like spheres or axis-aligned boxes). You test your point against the bounding volume. If the point is inside, then you recurse into that bounding volume. If the point is not inside, then you can ignore that entire branch of the tree and check the next bounding volume. At the leaves are the actual objects in your model world.
With some approaches, the tree is implicit, but the idea is the same. When you binary search through a sorted array, you're doing a tree search even though there's no data structure explicitly modeling the tree.
Two-dimensional versions of these structures can map mouse or caret positions in screen space to a point in document space (and sometimes vice versa). The spatial map is used not only locate the caret, but to optimize the rendering by know which parts don't have to be "painted."
The actual document model might be a tree that follows the logical structure of the document (chapters, containing sections, containing paragraphs, containing spans of style settings, containing strings of text, containing characters). Or it might just be a long sequence of characters.
Imagine the entire formatted representation of your document is like a tall bitmap image. What the user sees on the screen is a rectangular portion of that bitmap selected based on the scroll position and zoom settings, so it's just a little arithmetic to convert an x, y mouse position to a (u, v) coordinate in our "bitmap space."
Our spatial subdivision structure could be a tree of nested rectangles that carve up the bitmap space with leaf nodes that refer back to positions in document space. This would allow us to query with a (u, v) coordinate to get a document location in O(log n) time.
Unfortunately, it can be difficult to keep a spatial data structure up-to-date as the document is edited. If the user types a character on page 1 of the document, you'll have to reformat the entire line. And maybe the paragraph. And that might affect the vertical position of everything else down the document.
We can slash the amount of bookkeeping necessary for these ripple effects by using parent-relative coordinates for the rectangles and document positions in our subdivision tree. An edit that adds or deletes a leaf node affects (at most) only the sizes of its ancestors and the offsets of its younger siblings. That's O(log(n) + m) where n is the length of the document and m is the number of younger siblings.
As with many subdivision algorithms, once you drill deep enough, it's often faster in practice to finish the computation with a linear algorithm over the remaining items than to recurse all the way to the conclusion. For example, maybe you'd use a subdivision structure that maps a (u, v) coordinate to a particular line of text and then scan the line to figure out the precise character position within that line.