Apple: how text search should work

My own sense of how the simple text search functions built into word processing, text editing and a variety of other common apps was probably forged by Apple's early usage patterns for this field (or was this a case of Microsoft doing something right?). It's simple, really: you invoke a key combination or menu function, and a dialog pops up to let you type out the pattern you'd like to find within the document you were last looking at. There are some other functions that are nice to have:

• Do you want to search forward or backward from the present spot?
• Must the case of the letters match?
• (in a fancy app such as a code editor) will there be regular expressions in the search criterion?
• (almost always) if the application can modify the text, other fields to permit search-and-replace

And, lastly, there are some contextual factors to consider, most notably: what should be in the text area where you enter the search string when the dialog box appears?

It seemed that there was a consensus of how this should be done, and things were spiffy: if there was text selected in the document when you pressed cmd+f, the selected text would be copied into the search box, affording you an easy means of double-clicking a word and hitting cmd+f and then enter to find the next occurrence.

In a thoughtful embodiment, successive presses of enter on the search box (or cmd+g from any context) would find successive occurrences of the search string. If there were no text selected in the document when you pressed cmd+f, the search box would come up blank or with the previous search string entered and selected, which offered a convenient alternate means to repeat a recent search. The fact that the text would be selected, however, meant that typing any new search string at all would replace the old one. This kept the fresh-start case from being even a tiny hassle. Though you still can find apps that do this precisely right (e.g., the "search within page" function in Firefox), life was good when apps abided by this pattern or a near variation.

But suddenly, the apps that seem most vital to me on the Mac do it pretty darn wrong. They offer no advantages, only shortfalls from the pattern described above. TextEdit (v1.6) and Dashcode (v3.0.1) do not take any text selection from the document when their cmd+f search box is invoked -- they present the previously searched-for text. If you want to search for a word you've selected, rather than the two steps of cmd+f/enter, you must perform 4 steps: cmd+c/cmd+f/cmd+v/enter to achieve this very common desideratum. However, they add a second search function ("Use selection for find" ... cmd+e) which behaves totally differently. It does not actually perform a find at all, but simply copies the selected text into an unseen buffer of what WOULD be in the search box. Actual searching is achieved by subsequent use of cmd+g or shift+cmd+g. Pressing cmd+e when there is no text selected greets the user with a "bonk" error tone... as if he made a mistake of some kind ... stupid user.

Proving that more thought can only be more toxic, X-Code (v3.2.2) takes the cake. It starts with the same behavior of the smaller and adds a third function, ("Find selected text"... no cmd key shortcut) which almost works as you'd like, but it does so without a searchbox being present, which denies you access to any of the other options this box affords (if could be summoned via cmd+f). Here again, the case of your using this function when there is no selected text is rewarded by a "bonk" tone.

Why are so many "behaviorful" functions created when the problem and its sub-cases are so simple? If there is a plausible rationale for why anyone would prefer the approaches taken in these apps to the simpler and more flexible pattern defined above, I'd like to hear it. I would like to feel this is an embarrassing situation of the right way being patented, as I'd tend to think only someone hamstrung by the exigencies of our patent system could prompt Apple to produce such an almost Soviet-style solution to text search. 

Take Away Apple... make your text searches as easy as cmd+f, cmd+g, shift+cmd+g -- with additional options for text replacement and such being available on a find panel that can be dismissed by pressing escape. Your present approach is elephantine and requires the user to mull a variety of tools when only one is needed.