Indexing Terraform Files

Hello, I have trouble indexing Terraform files (file.tf). I have installed the “Syntax Highlighter.app” (GitHub - sbarex/SourceCodeSyntaxHighlight: Quick Look extension for highlight source code files on macOS 10.15 and later.) and Quicklook displays the files successfully.
Devonthink also renders these files if I just select it.
However, searching for contents in *.tf files is not possible.
How can I index Terraform files with DT?
I am using DT 3.9.7 on MacOS Ventura 13.3.1

Quick Look plug-ins support only displaying, indexing requires a Spotlight plug-in.

Correct me if I’m wrong but Terraform .tf files are plain text. So what exactly do I need a Spotlight plug-in for?

In this case the hidden preference AdditionalPlainTextExtensions (see appendix of help) should be sufficient.

If you use the following for example:
defaults write com.devon-technologies.think3 AdditionalPlainTextExtensions -string .ps1.tf.sh

.tf files are still not searchable in DT.

This hidden preference affects only files imported afterwards.

Any idea how to “enable” it for already imported files?

Import them again?

Only by rebuilding the database.

Yes, that’s what I suspected, unfortunately. :grinning:

I’m curious. Why is rebuilding as @cgrunenberg suggesting “unfortunate”? Doing it once will catch up on all the un-enabled files and after that all works (if I’m reading the above posts correctly). Rebuilding probably can’t take that long and even if a “long time” is it not worth it?

1 Like

Unfortunate, because it simply takes a lot of time with large databases. I would prefer a faster way (re-index or something) if possible. But yes, rebuilding the database is a possible work around.

Sounds like you have done a rebuild before. How long did it take and is this time not worth it considering your stated need for it to work? A way forward for you is offered but not good enough?

Too long in my opinion. And yes a rebuild is a workaround and yes it’s not good enough because there’s always room for improvement, isn’t there. If you prefer stagnation, that’s up to you, but I don’t have to be satisfied with that, right?

How would you quantify “too long”. The time to rebuild a database is relative to its size and contents. The larger the database and more textual content, e.g., many PDFs versus many images, the longer the rebuild takes. That’s completely logical.

1 Like

FYI this statement involves two distinct predicates: that (1) you are hoping for the better, and that (2) the present is in a desperate condition “stagnation”.

Perhaps your “stagnation” point is just provocative language. Perhaps it’s a genuinely held view. I’m sure you already know this, but still I want to say: You certainly can be positive about the future without being angry and disgruntled about the present.

3 Likes

I don’t understand what’s wrong with you. Firstly, to be clear, the current solution works and the duration is of course dependent on the size of the database. That’s completely ok with me. But secondly, you can think about improving the process, e.g. developing a re-indexing or similar. I am not the developer and do not know if the current solution is really the ‘best possible’ solution. Apart from that, this process is not something I use (or have to use) on a daily basis.

I wasn’t complaining, I was just suggesting a feature. But hey, keep discussing, the wasted time is clearly too much for me now.

Sorry to hear that you have wasted precious time by… confusing yourself? Anyway, have a good weekend.

3 Likes