Are you one of those people that has ever, not found something?
Aha! this is for exactly people like you!
…lets you add keywords to locate tiddlers in standard search. This is not the same thing as “tags”; keywords can be anything, they are not directly visible and you can even add them to otherwise hard-to-find shadow tiddlers as keywords don’t overwrite or otherwise affect the tiddler.
Check it out.
(BTW, a much older variant of this is SearchWords but Keywords is just better)
Psst—you’ll probably want to change
<table class="mvtw-keywords-delete">
<$list filter="""[[$:/plugins/TWaddle/Keywords/keywords]fields[]!is[tiddler]!is[shadow]] -created -creator -modified -modifier -title -tags -text""">
to
<table class="mvtw-keywords-delete">
<$list filter="""[[$:/plugins/TWaddle/Keywords/keywords]fields[]is[tiddler]!is[shadow]] -created -creator -modified -modifier -title -tags -text""">
in $:/plugins/TWaddle/Keywords/keywords so that your helpful table will show up. 
This is very clever, and I can definitely see myself using it. (If I can get it to play nicely with my CSS… at the moment, it seems to display by default, rather than only on hover.) Kudos!
ETA: You may have already considered this, but I think I may also tweak it to store data in indexes in a data tiddler rather than in fields… I find I’m always ending up with too many fields as it is. 
Hm, the idea for that particular list is that if the keywords tiddler has field that is neither a tiddler nor a shadow, then it should be listed so the user can remove that field. No listing should show otherwise.
That’s interesting. Exactly what shows, actually? The whole field, or just the “keywords” prompt? Does it only show in your personal wiki or does it also show at my plugin site? What browser are you using?
I never used a JSON tiddler as a data tiddler, if that is what you mean? I have however used dicitionary tiddlers but they are too limited and don’t allow titles containing the : character for indexes. What would be an advantage with a JSON storage over fields, if that is what you mean? Besides, what is a problem with “too many fields”?
I obviously wasn’t reading very well - my bad! I glanced at it, saw two similar lists, and assumed you had one section displaying only missing tiddlers and another showing all the extant tiddlers with keywords.
I’m using Firefox, and I’m pretty sure it’s just conflicting with my local CSS: the whole field shows in my pesonal wiki, but it looks great everywhere else. Not your fault!
(Edit: on further investigation, it looks like maybe the stylesheet just isn’t getting applied?)
I use dictionary tiddlers if I’m building them myself, but $action-setfield $index="" or $edit-text index="" will default to JSON structure if you haven’t already set the type of the target tiddler, so I often use them the same way I’d use a field for “behind the scenes” data storage.
Mostly, that I have 637 of them already, and my untested and perhaps erroneous assumption is that this is not helping with my wiki’s efficiency. If nothing else, it makes the field name hint dropdown ungodly long.
I realize that number does not sound like someone who cares about limiting the number of fields. I am trying to cut back.
That, sir, gets this week’s UI-UX prize 
Hi @twMat,
Thanks for sharing, I like your plugin: simple, elegant, good UI… Very useful! Bravo!
May I suggest you pack the $:/core/ui/DefaultSearchResultList modified shadow tiddler with the plugin? Without it the tiddlers with matching keywords didn’t appear in search results in my wiki, even after I installed your plugin.
Fred
@tw-FRed - thanks for your kind words
Did you check the box for “Enable standard search to also search keywords” in the setup?
My reasoning for not including that shadow tiddler, even though it is overwritten when that checkbox is clicked, is because some people may already use a customized such tiddler. Checking/unchecking the mentioned box only appends/removes the special search filter in that tiddler, so people can keep on using their custom search results with my plugin. (At least I think it should work, but I didn’t test that aspect.)
My mistake, it works exactly as intended!
Thanks for your fast answer 
Fred
Awesome!
For those who employ a tool to simplify UI for non-authors (such as ReadOnly), you’ll probably want to add the following to your read-only css:
.mvtw-keywords-wrap {
display: none;
}
I do wish we had some standard community-wide way for plugins to flag or list elements that are likely to be targeted for differential author/reader treatment (saving users the steps of poking around with browser’s Inspector tool to find the right selectors, and/or searching for info here).
Alas, I don’t have much perspective on what that would look like, in practice.
Perhaps such info could at least be included at a plugin’s demo site?
An interesting plugin, I don’t see myself using it as is, but I like the idea of assigning keywords and the UI! A somewhat simpler solution I use is an title-alternative field, which is displayed below title and included in title search.
Out of curiosity, what are the advantages of storing the keywords not in the tiddler? It makes me feel uneasy somehow. I see some reasons, but for me, they are not enough to convince me if compared to storing keywords in a keywords field of the respective tiddler:
A main reason is so you can add keywords to shadow tiddlers, i.e without overwriting them. Further, it is significantly easier to transfer/copy your keywords to other wikis if the keywords are stored in one central place.
Agreed. I’d add, whether or not you’ve chosen the right/best way to store them, not adding them to the target(s) is an excellent idea. Damned clever and bravo!
For me it’s OK to avoid modifying shadow tiddlers. But for existing “content” tiddlers it should be part of the tiddler itself.
How did you ask standard search to use that shadow tiddler? I read the code but didn’t figure out how. Thanks.
Native TW uses the field first-search-filter in the tiddler $:/core/ui/DefaultSearchResultList, so this is the field I manipulate.
In the plugin …/setup tiddler, at the very bottom, there’s this:
<$checkbox
tiddler="$:/core/ui/DefaultSearchResultList"
listField="first-search-filter"
checked="""[[$:/plugins/TWaddle/Keywords/keywords]fields[]!title[text]]:map[[$:/plugins/TWaddle/Keywords/keywords]get<currentTiddler>search:title<userInput>then<currentTiddler>]"""
unchecked=""
...
>
So, this checkbox widget treats the first-search-filter field as a listField, i.e the checkbox appends the filter defined as the checked value to the default search filter. I did not want to merely replace the existing filter as the user may already be using a custom filter.
Different use-cases have different needs.
Suppose I regularly batch-import tiddlers (from moodle, using an importer that you helped me build 
), and I want not to modify them-- because I want the modification date to remain unchanged, and want to keep the import process streamlined to recognize duplicates, and also because they’re a kind of archive of what the students submitted… BUT suppose a student used the title “existantial dillema”, or I want to specify a synonym that’s not in their text, etc.
So, I don’t want to edit the tiddler that represents the student’s work in order to improve the metadata for searching. But I do want to find it when I search for “dilemma” or “existential” etc.
For such reasons, the approach by @twMat is helpful to me, even for non-shadow tiddlers.