is/all operators to include fields and new system fields! V5.2.0

[AnthonyMuscio]

Folks,

Would it be possible to add to the next version is[field] and all[fields]] such that a title can be tested to see if it is a fieldname?

The following filter can already determine this;
[fields[]match[test-field]then[yes]else[no]] equivalent would be [[test-field]is[field]]

However since fields are a important element of tiddlywiki, it would be helpful and make readable a range of field handling designs.

An extended feature would be to have virtual tiddlers for such fields like tags currently have a virtual tiddler, you can open and create if desired. This will be even more appealing with the new expanded tiddler naming rules because one could arguably have system fields ie those beginning with $:/ which are optionally hidden from view and edit templates, but certainly will not come up in the sidebar search.

An added feature of the extended field naming in 5.2.0 is designers and developers can use fieldnames with their own prefix eg I use $:/psat/tiddlername I can also use $:/psat/tagname so it would be nice to use $:/psat/fieldname

Regards
Tones

[AnthonyMuscio]

See also #5315

[pmario]

The following filter can already determine this;
... equivalent would be [[test-field]is[field]]

IMO this is already possible with [has[test-field]] ..

The is operator doesn't return yes or no, it returns the tiddler title, if the operand matches.

[AnthonyMuscio]

Still is/all tag is/ tiddler exist why not is/all field as I want to get titles that are also fields not just test if a named field exists.

It's about consistency.

[pmario]

IMO this suggestion should be closed and a new one with the $:/ prefix proposal should be created.

Or you can change the title to "Allow system fields that have similar characteristics as system tiddlers" ... and remove the is and all suggestion from the OP

[pmario]

I think it's not possible to implement a "system-field" behaviour into v5.2.0. There is a lot more to think about.

I think, it will affect the UI, core code and probably break some wikitext and internal parsers. We will need some heavy testing here.

[AnthonyMuscio]

I will seperate into two ideas as requested!

[AnthonyMuscio]

The question about system fields is likely to arise again with the 5.2.0 changes. Much of the functionality will be easy but as you say testing is the big question but this testing is only a subset of what must be done for the new arbitrary fieldnaming change.

[pmario]

@AnthonyMuscio I did write down my thoughts on system-fields at: #5805

[Jermolene]

Hi @AnthonyMuscio at the moment, all the variants of the "is" operator just need to look at each tiddler individually in order to match it. The [fields[]] operator in your example is actually equivalent to [all[tiddlers]fields[]] which is intrinsically slow because it involves scanning all tiddlers to get a list of the fields that are in use. It would be confusingly irregular to have some variants of the is operator with wildly different performance characteristics.

So, while there may be a case for the functionality you're after, it would have to be via a mechanism other than extending the "is" operator. But a deeper concern is that your request is already possible; it feels like a premature request to abbreviate the expression.

[AnthonyMuscio]

Jeremy,

I do not know how the [is[tag]] works but I was hoping we could have the same methods for the [is[field]]. As suggested, just as a tag is usable without a matching tiddler existing, but if you want you can create a matching tiddler eg; $:/tags/Macro we could have a tiddler called fieldname eg "description" or $:/fields/description. The just as we can for tags we can load the field tiddler with information about that field.

Is it a matter of introducing an internal cache of fieldnames or some other technique similar to tags?

The reason I am prompted to raise this is the extended possibilities with 5.2.0 fieldnames.
[[tiddlername]is[field]then.. is more likely to be asked.

Regards
Tony

[Jermolene]

As I said before, this request is already possible; it feels premature to try to abbreviate the expression without a much stronger rationale.

[AnthonyMuscio]

Sorry I am late to respond. I think perhaps because I do think "to abbreviate the expression" is of big enough value, in an attempt to bring the field into more prominence. I would like the field to be treated as pivotal as all the other tiddlywiki objects, perhaps even more now it may prove hard to distinguish a field from a title with the new opened file naming.

And perhaps I can now get a new macro for in filters with parameters " or "" which is a role your own filter operator equivalent.

however I do bow to your greater understanding, as far as provisioning it in the core. Thanks

Tony

[AnthonyMuscio]

As I said before, this request is already possible; it feels premature to try to abbreviate the expression without a much stronger rationale.

Sure, Let it be for now. The rational to me was make the filter more English like thus its a value judgement and dependant on the population of users and the ways they think - little of which we know. There may also be an opportunity with the field name freedom to achieve something similar eg has[Customer Details].

So I am happy to set it aside. Thanks for thinking about it.

[AnthonyMuscio]

I feel this discussion has come to an end, see my last reply, is there a way for me to mark it closed or complete?

[Jermolene]

No, GitHub discussions doesn't support anything like that.