Advanced PerfectIt Wildcard Checks: Exceptions, Order, and Clashes

Adding PerfectIt wildcard checks to a style sheet is straightforward. Getting a style sheet full of them to behave as a coherent whole is a different skill.

A Word wildcard search runs in isolation, whereas a wildcard check in PerfectIt runs within a sequence of other checks: some run before it, some after it, and, crucially, every other wildcard check in the style runs alongside it. That last point causes more confusion than anything else here.

 

Exception rules

Exception rules let you keep a general rule general and deal with the awkward cases separately. They come in three forms:

  • Except before — skips a match when the Find term appears before any listed term

  • Except after — skips a match when the Find term appears after any listed term

  • Except for — skips a match when it forms part of any listed term

You write them into the Instructions column. A Preferred Spelling check changing spelt to spelled would want Except before “flour,” “bread,” “berry,” and “berries,” so the wheat survives. Only the literal words listed are skipped, so plurals and inflections each need adding.

PerfectIt recognizes those three phrases and hides them from the instructions users see, so they don't clutter the interface.

They work with wildcard checks too, with two things to watch.


Build strings that match whole words

Take the re-e check from before. It needs exceptions because you don't want reed, reel, and reef becoming re-ed, re-el, and re-ef. Since the string uses @ and <>, it matches whole words, so the exception list reads naturally: Except for "reed", "reeds", "reel", "reels", "reef", "reefs" and so on.

Write the same check to match only the beginning of the word, <([Rr])ee, and your exception list becomes "d", "ds", "l", "ls", "f", "fs", which is considerably harder to reason about and easier to get wrong. Using @ and <> even when you don't strictly need them makes exceptions far more legible. It also means PerfectIt highlights the whole word rather than a fragment, which is kinder to anyone using a style they didn't build.


Account for every part of the string

Even with a negated character class such as [!abc], the character it matches remains part of the Find term, so your exception rules need to account for it.

 

Order: only three things run first

The Wildcard Find & Replace check sits between Similar Words and Preferred Spelling. In practice, that means only the hyphenation checks, the en dash checks, and Similar Words happen before it. Everything else comes after.

So, there are two questions to ask of any wildcard check: could a later check undo this change, and has the step it relies on actually happened yet?


What's already done, you can build on

PerfectIt has settled your hyphenation, and the hyphens it inserts are ordinary ones. If you'd rather they were non-breaking, this is the moment:

Find:     -

Replace:  ^~

The en dash checks are finished too, so you can manipulate dashes without a later check reversing you:

Find:     ([0-9,.]{1,})-([0-9,.]{1,})

Replace:  \1^=\2

That turns 1-10 into 1–10. Watch the Style Points setting for spacing around dashes, though: it ignores hyphens and minus signs but may flag your new en dashes if your preference is em dashes. Don't press Fix All on that one blindly.

 

Your string must allow for what hasn't happened yet

Your style sheet specifies vitamin A, and you've added the vitamins to Capitalization of Phrases. But that check runs after yours, so when your wildcard string looks for vitamins, the lowercase ones are still lowercase:

[Vv]itamin[ ^s][A-Ea-eKk1-9]{1,3}>

The [Vv] allows for both cases; the second inventory covers the vitamin letters and forms such as B12. The same logic applies to accents: if São Tomé and Príncipe is in your Accents check, the misspelled versions are still misspelled when your wildcard runs, so a string touching that name needs S[aã]o, Tom[eé], and Pr[ií]ncipe.

There is a way to cheat all this. Because you choose which checks run, you can control where the wildcard check falls: run PerfectIt once with all the checks up to that point except Wildcard Find & Replace, again with only Wildcard Find & Replace, then a third time with the remaining checks.

 

You cannot chain wildcard checks

This is the one that surprises people, and it's worth stating plainly.

PerfectIt runs each check separately in a fixed order, but within a check everything happens at once. All your wildcard strings run simultaneously, then get presented to you in alphabetical order by Find term.

That rules out chaining: using one wildcard search on the results of another. It doesn't work here, however well it works in Word. By the time you click Fix on the first, the second has already run.

The workaround is a second style containing nothing but wildcard checks, with every other check switched off. Run your main style, then run that one afterwards for the follow-up passes.

 

Clashing

The same simultaneity creates a problem that can't happen in Word: two of your wildcard checks finding the same text for different reasons.

Say one check strips :00 from on-the-hour times and another adds full stops to am and pm. Both are sensible. Run them on 9:00 am, and you'll be shown the first check's hit. Click Fix, and you get 9 am. Excellent.

Then you reach the second check, and instead of a hit on 9 am, PerfectIt tells you the text has already changed. That check originally found 00 am, which you've just deleted. Undo won't rescue you; PerfectIt reports an error.

You can sometimes amalgamate the two into one check, which works when both errors are present but misses documents where only one is. Otherwise, that second style is the answer again.

 

The special-character bug

Here is one genuinely odd thing worth knowing before it wastes your afternoon.

When a Find string contains certain non-alphanumeric characters like the dollar sign (a known offender), recall can fail and PerfectIt writes a literal \1 into your document instead of the text it found.

The fix is absurd and completely effective: put the character in square brackets. ([$][0-9,]@).00 works where ($[0-9,]@).00 doesn't. It's an inventory of one, which makes no logical sense, and it solves it.

Finally: there's no limit on how many wildcard checks you can add, but the check is processing-heavy, and a style stuffed with them will noticeably slow PerfectIt down when it reaches that point.


Get the full guide, free

Brave New Word is our free ebook on Wildcard Find & Replace in Word and PerfectIt, by our in-house linguist Chris Ryder. Two full chapters cover PerfectIt. They show you how the wildcard check works, when another check would serve you better, exception rules, its relationship with prefixes, hyphenation, capitalization and accents, and the traps around clashing and chaining. Alongside those: the complete Word symbol set, dozens of worked examples by discipline, and a chapter on troubleshooting. There's also a printable cheat sheet at the back.

Previous
Previous

A Word Wildcard Cheat Sheet: Strings Worth Keeping

Next
Next

Word Wildcard Error Messages, Translated