I am posting in this topic to seek developer and core devs thoughts on this suggestion before placing a GitHub feature request, in particular @jeremyruston.
Tags are treaded favourably in TiddlyWiki with provision of the tag/tagging/tags/untagged operators which in effect make handling of a field (the tags field) containing zero or more titles, a list field, much easier. But also already, The tag picker macro has the tagField and actions parameter, Checkbox has the listField parameter.
In a recent reply I realised that people are finding more ways to use list fields for various purposes more often now, but presently they need to use list/enlist/enlist-input or the subfilters of the action listops widget, which get a little more complex and restrict use of the list field code pattern to more experienced users.
Then is dawned on me;
Lets reuse the current pattern to deal with any fieldname, it also allows users to transfer what they learn about tags to any list field.
Could we not simple enhance the tag/tagging/tags/untagged operators to accept as a parameter the fieldname, defaulting to tags, and provide us all with a helpful set of tools?
- Alternatively introduce a new set of operators that are effectively the same but accept a fieldname. I am not yet sure what it may be named but fieldvalues may be one. eg somewhat in Jest, pending alternate names.
- tag[] → fieldvalue:fieldname[]
- tagging[] → fielding:fieldname[]
- tags[] → fieldvalues:fieldname[]
- untagged[] → unfieldvalue:fieldname[]
- Similarly the has operator could be extended to test if a field has the named title within it, not just that the field exists/has a value. “has::fieldname[title/value]”.
- Perhaps we could even use the existing tag handling elements view/edit templates with a parameter to operate on any field as if it were a tags field.
I think this would be a simple, possibly low byte enhancement that would extend the ease of using list fields a lot more, and helping stop the over use of tags.
[Edited] Actualy I should have explored the list / listed operators here, so perhaps we can move to lists…