I don't know if this is relevant, but many times when I go to any kind of file dialogue or even just click on some tool or something, I get a few seconds (or more) of beach ball while my second HD (non-boot drive with most of my documents/non-OS files) wakes up and gets up to speed. I can hear it revving up and when it gets to speed the OS unfreezes… so maybe if your file directories are being cached in memory or the drive cache, when the HD wakes after 30 secs for whatever reason, it updates the directory lists in memory?
I'm thinking this isn't super common complaint so maybe it's HD settings specific like my problem (I think I set my 2nd HD to have energy saving options somewhere when I installed it and haven't found a way to have it spinning 24x7.
This likely is a result of the editor/software for TEX you use since you don't need any spotlight importer to process plain text files. (So you could just delete your app's custom importer or choose an update/different importer).
Rather than guess at the case - here's how to nail down where the problem lies. The editor could be changing the ** kMDItemContentType** to one that's not indexed or you have a third party spotlight extension that's crashing. Here's how I'd know which of these (or something more unexpected) is happening:
A) Does spotlight index an arbitrary text file when you change the extension from .txt to .tex?
B) Compare metadata for the files to know what's happening using mdls
To test A, open Text Edit and paste one word into the document: osteoporosis
If needed, convert the document to plain text (it's probably rich text) - Shift + Command + T (or use the format menu - Make Plain Text) and save it to your desktop as file.txt - If the format menu says Make Rich Text then don't press the keys and just save the document.
At that point, spotlight should see the file immediately. If not, you have spotlight problem and not .tex file problems. This is a very basic problem if your spotlight is broken so as not to index plain text files. If this work, then change the .txt extension to .tex and re-check spotlight.
For test B - use the mdls command to examine the metadata differences between your file and the TextEdit file that work with spotlight. Pay special attention to the following fields:
kMDItemContentType = "public.plain-text"
kMDItemContentTypeTree = (
"public.plain-text",
"public.text",
"public.data",
"public.item",
"public.content"
)
kMDItemKind = "Plain Text Document"
Changing the .txt to .tex causes a change to this (since I have no application that claims the file extension of .tex and maps it to a launch services/spotlight classification and proper kMDItemContentType/kMDItemKind as opposed to a generic and ad/hoc type:
kMDItemContentType = "dyn.ah62d4rv4ge81k3p2"
kMDItemContentTypeTree = (
"dyn.ah62d4rv4ge81k3p2",
"public.data",
"public.item"
)
kMDItemKind = "Document"
Here's a short test you can cut/paste if your terminal skills are not yet developed. It would delete the contents of any file names test_file on your desktop so make a backup if you're not sure before pasting the commands below:
cd ~/Desktop/
echo osteoporosis > test_file.txt
mdfind osteoporosis | grep Desktop
mdls -name kMDItemContentType test_file.txt
mv test_file.txt test_file.tex
mdfind osteoporosis | grep Desktop
mdls -name kMDItemContentType test_file.tex
The mdfind commands are the equivalent of using Spotlight, so check that the terminal search matches the spotlight search at that moment.
As a footnote, these tools are only needed to diagnose the extent of breakage and not a substitute for spotlight search in the end. Just that you can't diagnose a spotlight issue with spotlight alone. Also, you might want to watch the console log while you are doing the steps in ~/Desktop in case there are crash reports or other spotlight diagnostics happening while you are poking at the subsystem.
Also, things get nasty quickly if you can search the plain text document but not the text one. In your update, you mentioned that .tex files are of type "org.tug.tex" - you could explore the launch services database to find out what importers the system things is responsible for parsing this file and remove them (or just make an educated guess and temporarily delete the TEX apps to see if it "fixes" spotlight temporarily).
lsregister -dump| grep -n7 org.tug.tex
Where lsregister is a well-hidden tool in /System - see this thread on SuperUser to read up on launch services: https://superuser.com/questions/323599/ and this thread here: Duplicate entries in "Open With" menu in Finder even after rebuilding Launch Services for some oddball things to try. I'm fairly confident I could suss out what's amiss on your system in about 20 minutes of poking, but writing down all the possibilities in a way accessible to you and guessing a bit of the answers is proving harder than I expected.
Best Answer
A simple Finder Spotlight search can do this. Navigate to the Folder you want to start the search from. Type Command F, and then enter the search criteria:
I'm not sure what you mean by keywords: do you mean metadata describing the file, or some actual text in the SVG? You could try the "Contents" token for the latter.