June 15th, 2012 • 8:53 am
Yesterday I was revising a long report and want to change the format used for date ranges by replacing the regular dash with an en dash. In other words, I wanted to replace all occurrences of a date range like “2010-2011” to “2010–2011.”
And of course I wanted to do the exact same thing for all date ranges.
This is an area where Microsoft Word has a clear advantage over Apple’s Pages ’09, because it has an advanced grep-like feature in its Find/Replace dialog box — although you wouldn’t know it from looking at Word’s help, which is woefully inadequate. It does talk about “using wildcards to find or replace text,” but gives you absolutely no clue about what to put in the “Replace with” box.
Sure, people who are familiar with grep features will know how to figure it out themselves, but still, how much would it have cost them to indicate that you can use
\2, etc. in the “Replace with” box to insert the found strings matching the expressions in the “Find what” box?
In any case, it didn’t take me too long to figure out that I could use the expression “
([0-9])\-([0-9])” in the “Find what” box and then “
\1–\2” in the “Replace with” box:
(I am using a small sample document here instead of my large report, for illustrative purposes. But the situation is the same. And I know the en dash in the “Replace with” box looks exactly the same as a regular dash. That’s because Microsoft uses an inappropriate font in this dialog box. But it is definitely an en dash. And if the font that your browser uses to render computer code is a monospaced font such as Courier, you will probably not see the difference in the body text of this blog post either.)
But then when I hit “Replace All” I got something like this:
WTF? I first thought something might be wrong in my expressions. Given that I am accustomed to Microsoft Word‘s quirkiness (to put it mildly), I didn’t rule out the possibility that it had a specific “flavour” of grep with unconventional requirements. But try as I might, I couldn’t find any solution. I tried replacing the en dash with a simple string of characters, in case Word 2011 treated the en dash as a “special character” that would cause problems in grep expressions. I also tried escaping it. It didn’t make any difference.
Finally it hit me: What if the problem was linked to the fact that I was using Track Changes on this document? I was revising the report, and my client needed to be able to review the revisions. But in order not to affect legibility, I had Track Changes on with the markup hidden, so that I could focus on the text and not be distracted by all the extra cruft that the Track Changes feature displays:
Sure enough, I turned Track Changes off and tried again, and:
No problems this time!
So the conclusion is fairly simple: As soon as Track Changes is on, it becomes impossible to use wildcards to find and replace text in a Word document, unless you can live with the unreliable results. So much for being smart and using regular expressions to correct documents!
In order for the grep feature to work properly, you only need to turn Track Changes off. You don’t need to approve all the existing tracked changes. You just need to turn the feature off temporarily when using wildcards to find and replace text.
There is an alternative, which is not to use Track Changes at all while revising the document, and only use the “Compare Documents…” command at the very end to compare your revised version to the original. Word then produces a new document that is effectively the original document with all your changes inserted as tracked changes, including the wildcard-based find/replace operations.
But it still is a typical Microsoft problem. The software has become so complex, with so many features, and no one at Microsoft apparently bothers to properly test the use of several different features simultaneously on the same document. Yes, you can use Track Changes. Yes, you can use wildcards. But don’t use them both at the same time! Of course, with so many features, the possible combinations of features are innumerable. But it’s the same with any kind of complex software. Microsoft should know: their bread-and-butter is an actual operating system. The possible uses of an operating system are innumerable. An operating system contains tons of different features, and many of them can be used simultaneously. If you cannot test all the possible combinations, then you need to make sure you have a robust design in the first place, which is built from the ground up to be able to handle an endless range of possible combinations.
With the spaghetti-coded software known as Microsoft Office, there is simply no way that we’ll ever have this kind of robustness. And so we users are forced to live with all kinds of bugs and feature incompatibilities, such as the one described above — which can have a very real and very dramatic impact on our work.