Great idea! Apple should implement this Safari-style find in TextEdit.

[ Reply to This | # ]

Vim does much the same thing. The only difference is that it doesn't gray out the rest of the text, but it can highlight search matches. To use this feature, enter :set hlsearch, then enter /your-search-phrase. To move to the next hit, type n. Also useful is :set incsearch to jump to the first hit as you type. ///ark

[ Reply to This | # ]

You can assign a keyboard shortcut to toggle the hlsearch options:
map <F6> :se number!<CR>
map <F7> :set hlsearch!<CR>

in your ~/.vimrc file - then F6 will toggle line-numbers (Which is useful since copy/pasting breaks with line numbers on), and F7 to toggle highlight search

[ Reply to This | # ]

Emacs does this too using (by default) Ctrl-S and Ctrl-R

[ Reply to This | # ]

Nice. It seems to choke on UTF encoded text files, however. But the white on gray is nicer than the Firefox yellow highlight.

[ Reply to This | # ]

Have you tried TextWrangler? It can find multiple occurrences in multiple files, and returns a list of every hit, which you can then click on to see more context immediately in the results window.

[ Reply to This | # ]

Yes, I do use TW as well (because it is more powerful, with customizations), but sometimes the Safari UI is just cleaner and more to the point.

[ Reply to This | # ]

Nice, insightful tip!

I knew that Safari has a better multi-instance Find feature, and I knew that Safari can open some text formats, but somehow I never put 2+2 together...

[ Reply to This | # ]

I might have missed something, but if you drag any file onto Safari (an icon or window) it will attempt to display it.

One limitation seems to be that it doesn't do the grey-out trick if there are more than 100 instances of the found text.



[ Reply to This | # ]

Correction - not 'any" file :-)

But it did work with .log files and a few other text files I had lying around including some without an extension. I guess there is some sort of rule here, but it's not obvious to the casual observer.

[ Reply to This | # ]

You can look at any text file from the command line using grep --context=2 'regular expression' name_of_file. That will get the job done!

[ Reply to This | # ]

grep --color highlights the hits.

///ark

[ Reply to This | # ]

I use this trick frequently. It's really nice!

[ Reply to This | # ]

I keep line numbers on and haven't had any problem with copy and paste. I use Carbon Vim, not MacVim. Could you elaborate?

///ark

[ Reply to This | # ]

Another great tool to do this job on the command line is ack: http://petdance.com/ack.

It is faster than grep, highlights the search hits, and shows any number of surrounding lines around the search hits.

[ Reply to This | # ]

While I really like Safari's improved Find interface, there is one signifcant disadvantage in using it for searching text files: it doesn't handle multi-megabyte text files very well. And to some extent, vi(m) is also somewhat slow with large files.

Textmate and other GUI text editors are great overall, but why not use a tool that is pre-installed on every OS X system. So for searching large files, and still having the benefit of your search-pattern highlighted, you should ideally use the "less" utility via Terminal. less is a pager, it loads one page at a time for display, so it is instantaneous in working with enourmously huge files (virtually no size limit). It's quite simple to use; in Terminal type (without the brackets):

less [filepath/yourfilename]

... then to search within your file, type:

/yoursearchpattern

... to go forward, backward, within your file (while still in search-highlight mode) type:

n, or N

... AND, you have the added benefit of being able to make use of some simple regular expressions to make your searches more powerful (in Safari or TextEdit, you can't).

less also holds your search-patterns in memory, if you have not exited your file; so to see or edit your previous searches, just use up-arrow, or down-arrow, after typing / (ie. "slash", to do a search).

--
So remember, less is more.

[ Reply to This | # ]