Simultaneous vs sequential find and replace
Why running many replacements at once avoids the chaining bug that breaks a naive one-rule-at-a-time approach, with worked examples.
The trap in one-at-a-time replacing
The obvious way to apply several replacements is to run them in order: do the first across the whole text, then the second, and so on. It works until two rules interfere. Suppose you want to swap two placeholders, changing A to B and B to A. Run them sequentially and the first pass turns every A into B, then the second pass turns every B, including the ones you just created, back into A. You end with all A and none of the swap you intended. This chaining problem is subtle because each rule looks correct on its own.
How a single pass fixes it
A simultaneous replace scans the text once and decides each position against the original characters, not against text an earlier rule already changed. When it writes a replacement it moves past it and keeps reading the source, so the output of one rule can never become the input of another. That is why apple banana, with apple mapped to banana and banana mapped to cherry, comes out as banana cherry: the banana that replaced apple is downstream of the cursor and is never reconsidered.
Longest match wins
When several rules could start at the same character, the tool prefers the longest matching term. This mirrors how people expect find and replace to behave: a rule for a whole phrase should beat a rule for one word inside it. Practically, if you map foo to one thing and foobar to another, the word foobar is handled by the foobar rule as a unit rather than being chopped up. Ordering your rules therefore matters far less than it would with a naive sequential approach, because specificity, not position, breaks the tie.
When to reach for whole word and ignore case
Two switches shape what counts as a match. Whole word only stops a short term from matching inside a longer one, which is essential when a common fragment like cat also appears in words like category and cats. Ignore case lets a single rule catch every capitalisation of a term, handy for cleaning up inconsistent text, though it inserts your replacement verbatim rather than matching the original case. Reaching for these deliberately keeps bulk edits precise instead of sweeping up words you meant to leave alone.