Personally, I don't think I have much need for tagging support. But that's what I thought about Everything itself at first, too. And look at me now
After some thinking, I came to the conclusion that - under the current circumstances - it is not possible to have a universal tagging standard.
Therefore, if Everything wants to index or even read tags, it has to accept that it needs to "understand" different file formats. Office document, images, MP3's, PDF's .. they all save it in a different place, using different synatxes.
Recently I discovered Disk Explorer Professional (http://www.tjelinek.com/main.php?section=d)
Basically, it's an EFU list "on steroids" as it also indexes tags, metadata and even preview of common documents (Office, pdf, images, movies). (Side-effect is that it's database size is 8+ times that of Everything ...)
It uses plug-ins to "talk to" he different file formats. They call those Filters. There is even an SDK to develop your own Filters.
I think that is also the route Everything should take, if it wants to index tagging information.\
Here's how I see that (this week
):- Under Options > Indexes there should be an extra entry: "Content" (but then a better name, perhaps).
- Here you can schedule the folders you want to scan for tags, including a schedule (basically the same mechanism/layout as Folder indexing)
- Further Content Indexing options include the Filters (drivers) to use.
Everything *knows* what files are changed or added. Those are the only files that need to be (re-) read for tagging info.
I don't think that Everything currently keeps track of deleted files, but that would come in handy, to prevent Everything from "ploughing" through the folder structure to find out what's new. (EDIT: when NTFS indexing is used; in case of Folder Indexing, Everything has to read the foldertree. Could scan for tags at the same time).
This tagging info are saved in one of those serverkess unstructured NoSQL database (like UnQLite; those are very good in storing key/value pairs an documents), as there are way too many different tagging keys availabe to create a proper structure for that (and those can/will change with an updated document layout)
Those NoSQL databases are really fast, btw
This database is separate from the current (filename) database and is *not* loaded in memory.
When some tags are queried from Everything, this database is read from disk. Otherwise Everything would occupy too much RAM (there are people here with 8 million and even 30 million files/folders!)
That is a little slower than reading from RAM, but beats scanning multiple terabytes of diskspace by miles.
For the result list: don't use separate headers for every possible tag-key. That's how Windows Explorer does it: adding a column for evey possible tag. Don't like that (although useful from time to time ..)
Instead, use column headers like Tag1, tag2, .. tag5 (number of columns shown configurable?).
And if you search for something like tag:2018. it will show for a matching picture in column Tag1: width = 2018 and for a matching mp3: year: 2018
That's it for now. Just a rough sketch. If I come up with more ideas/details, those will be added.
EDIT 1:
Don't think Everything should *write* tags. Thats the area of specialized software. Especially when document formats change (a new PDF layout, for example) and Everything isn't updated (yet), you might corrupt your tags, or worse: your document (I think; not sure).
EDIT 2:
(wild suggestion:) show the tags of a file in the preview window.