becker-charles makes Mike's redlining land where you point it
A rework of how the fork edits Word documents aims to stop tracked changes from landing in the wrong spot.
When Mike proposes an edit to a Word document, it has to find the exact passage to change and mark it up as a tracked change. becker-charles found the old approach shaky: it located text by fuzzy matching - searching for a snippet plus its surroundings - which could occasionally land on the wrong occurrence and fail quietly. The new version tags each paragraph with a stable identifier the first time a document is opened, so every edit points at one unambiguous location, and a mismatch now throws a clear error instead of silently editing the wrong line.
The same work retires a large chunk of hand-written document plumbing in favour of a maintained off-the-shelf library, and fixes a bug where the on-screen preview didn't refresh after you accepted or rejected a change.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?