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
As a (temporary) workaround, I'd use the
findcommand.In a new Automator workflow, add the following actions:
Run Shell Script
/bin/bashand Pass input:to stdinReplace the default
catwith:Move Finder Items to Trash
Note: As coded, this only deletes files at the directory level of ~/Downloads. It does not traverse subdirectories, so as to avoid deleting something Safari is downloading at the time it's run, as it uses a .download bundle which is a directory. You could devise a more complex
findcommand and or workflow, however this, as is, is better then your current nonfunctioning workflow.