Find/Replace
We turn now to the bottom level of Nisus, the area where the nitty-gritty is, the stuff that Nisus seems truly made for: the find-and-replace and macro/programming facilities.
You set up a find or find-and-replace in a dialog window, and the flexibility of what you can do is astonishing. You can include any sort of styling in your Find text or your Replace text – font, size, character styling, User-Defined Styles – as part of what Nisus is to look for, or the change it is to make. A built-in global regular expression parser ("grep"), or as Paragon was asked by Apple to call it, PowerSearch Plus, lets you build complex textual patterns to find and complex ways of dealing with them when they are found, and, in the Find dialog window, those not wishing to learn and type the cryptic, but oh-so-powerful codes to match patterns can select expression components from a menu instead. (It’s interesting to note that Nisus is one of a few programs that put menus in a window rather than further burdening the menu bar, something which is especially handy on large and multiple monitor setups. It would be nice to see more of this in the future.) You can find forward or backwards through a document, find one or all instances, limit your find to previously selected text. You can have your find performed on just the frontmost document, all open documents, or even on closed files for which you provide a list via the Catalog.
There is no point trying to enumerate all the features of PowerSearch Plus, but some examples will illustrate the power of the results. To change all instances of underlined text to italicised text is trivial. To change all instances of an imported marked-up expression such as "<it>some text<ro>", where the <it> and the <ro> may or may not be capitalised, so as to have the <it> and <ro> removed and whatever is in between become italicised, is only mildly less trivial. (That’s a real example in my life.) To find all instances of text that might be a phone number is an interesting challenge, but it is in fact possible to set up a single find that would be able to find such variations as "KI4-3459", "(607)-4215151", and "301 421-5353"; a single find-and-replace procedure might find all phone numbers regardless of their format and alter them so that they conform to some set format – say, parentheses round the area code if there is one, space after the area code, hyphen between the first three and last four digits of the number.
No doubt numerous possibilities for using all this power are occurring to you as you read, from free text databasing to file format translation – and rightly so. PowerSearch Plus (together with the macro capacity) is what I bought Nisus for, and it has done me yeoman service in this regard.
There isn’t much not to like about this wonderful aspect of Nisus. I have one suggestion, though. I often use foreign alphabets. Nisus’s PowerSearch Plus distinguishes numeric, alphabetic, uppercase, lowercase, alphabetic-with-diacritical, and punctuation characters, but these definitions are pre-defined for the Mac’s standard character set; the possibility that someone might be using a font where it is not true that a character is uppercase alphabetic if and only if it is ASCII 65-90, seems not to have occurred to Nisus’s designers. What I’d like to see is some sort of dialog that would let the user define these categories for any given font. Perhaps the new Script-Sensitive finding option present in Nisus 3.06 indicates some coming step in this direction; I’ve no documentation on it, so I can’t tell.
Finding text also responds inconsistently to the Keep On Same Page pseudo-style (see above). If text gets into the Find dialog that is marked Keep On Same Page (which can happen quite easily without the user’s knowing it if Copy is used to obtain the text to be sought), a style-sensitive find will not find text in the document unless it is marked Keep On Same Page (quite disconcerting, since the find will seem to be failing for no reason that the user can detect); but if the text in the Find dialog is not marked Keep On Same Page, then, even if the find is style-sensitive, text in the document that is marked Keep On Same Page WILL be included as a match. This is weird behaviour, but the root of the problem is really the fact that Keep On Same Page is a pseudo-style.