I use DEVONthink to index a few folders. Sometimes I use another application to edit files outside of DEVONthink in those same folders. That particular application has a certain behavior that interacts
badly in an annoying way with DEVONthink. I can configure that application to behave differently in selected folders, if I can figure out how to distinguish indexed folders.
This is probably a long shot, but: is there a way an external application could detect (by looking at the file system) that a given folder is indexed by DEVONthink?
I’ve tried to find look for a possible hidden file that DEVONthink might create, or a metadata property on the folder, and haven’t found anything, but perhaps I missed something.
(Yes, I could create something myself, or set a property. First I wanted to check to see if there’s something already available, or another trick that people use.)
This makes we wonder… Since the file is indexed, it’s stored separately and independent of DEVONthink, I’m curious. What application is it you are using that makes changes to files such that when you index/view the files via DEVONthink causes the “bad” interaction? What is it that you see that shows a “bad interaction”?
The issue is esoteric and I was trying to save time by avoiding needless details, but okay, for the curious:
I’m an Emacs user (since the mid-1980’s), and Emacs creates backup files before saving the first edit to a file [1,2]. Those backup files are named with a trailing
~N~ character sequence ; for example,
foo.txt.~1~. By default, the backups files are saved to the same directory as the original file . However, DEVONthink doesn’t recognize files ending in
~N~ as a known file type (which is perfectly understandable), but it does add the file to its index, which leads to the same file appearing twice in the indexed group listing in DEVONthink:
You can’t edit or view the file in DEVONthink (nor should you). I suppose calling this “bad” is not accurate – more annoying than bad. In any case, I can configure Emacs to change the backup destination  if I can find a way to tell Emacs what to look for. What I need to solve it is to know how to recognize the root of an indexed directory on disk, so I can write some Emacs Lisp code to either test all file paths for the pattern or test some part of the path for a property.
And here we are
 Just to be clear, these are finer-grained backups than, e.g., Time Machine backups.
 Before anyone mentions
git: these backups serve a different purpose from version control.
 The file naming name pattern can be changed – virtually everything in Emacs can be configured – but it would require too much time to change everything that depends on this, so that’s not a practical option for me. (It might be for other people, though.)
 The default destination for backup files can be changed, but it is extremely beneficial to keep them in the same directory as the original file in all other situations except for this issue with DEVONthink. Again, other people might prefer it differently. For myself, I would much rather solve this interaction than to change the backup destination for everything. I can do that if I can figure out how to tell Emacs when to use a special destination.
Excellent summary of the full situation. Those here who have experience or work in this world will know something. I will think on it, but probably above my pay grade.
Not entirely fruitful maybe but do a Google on “exclude files from index devonthink” for some ideas? As of writing those posts not possible to exclude files from index locations but maybe something has changed or the workarounds mentioned help. I did not read everything that closely, though.
I’m not aware of any defining feature, but of course @cgrunenberg may have details. The only thing I can come up with would be to use a smart group which shows indexed groups:
Then use a smart rule & script which e.g. applies a Finder label/tag/comment to those items in that smart group; would that be sufficient for Emacs to recognise?
Or add a suffix to the name of the indexed groups, this might be easier to recognise for Emacs.