Could we extend the tag/tagging/tags/untagged operators to allow an alternate fieldname

Developers
#1

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…

#2

@TW_Tones - is this summary correct:

Enable arbitrary fields to function like tag fields do by introducing/generalizing the various “tag operators”?

I would also find this useful and have requested it previously. @inmysocks created generic fields as tags (note also the reference list in my first post there). If I recall, there were some limitations to that solution that in the end made it insufficient but I don’t recall the details.

1 Like
#3

yes, that is an almost exact description of the GenTags plugin, the only things about it were that there is some special handling and caching that is used for tags that makes some of the operators on the tags field faster.

1 Like
#4

Yes, almost exactly like GenTags which really like and use, and can do almost everything if not all, in my proposal. In some ways Gentags, does even more. I did not mention it for brevity, yes brevity, and expected it to be raised in the thread.

Where my proposal is different is actually reusing the existing 4 tags operators with a fieldname parameter and/or the equivalent by another set of named operators.

The idea is just to make a minor extension ideally core changes, perhaps even without the GenTags tag bar etc… not because they are not useful but because now with cascades and alternative file templates they are easy to add with a non-plugin.

  • And again an important note is it is only an incremental change and easy for anyone who uses tags to apply it to other fields.
  • As they say, “imitation is flattery”, no seriously I would like to see Gentags or part of it become part of the core.
  • Part of this desire is the realisation is the functionality exists in the core but does not allow the fieldname to be provided. The equivalent of Gentags, which I recall working with @inmysocks during its initial creation, is mostly just a few bytes away, from the core, even if the user is left to do the alt-tags view and edit templates.
#5

@inmysocks , I find GenTags on github but I don’t understand how to download it from there so to actually install it in a TW. Is there a link to the plugin there or elsewhere? (The link inside your post inside the previously referenced gg thread does not work.)
Thanx

#6

https://ooktech-tw.gitlab.io/plugins/gentags/

I moved pretty much everything over to gitlab.

1 Like